MessageBox (ID:52712)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 >> マルチスレッドと(メモリ)リークの間に，何の関係があるのですか？ 政治的経済的な関係。 あるいは経験則的に、事実上の相関性があると考えます。 マルチスレッドにおいては経験不足・思慮不足による予期せぬ出来事のために 生成、消滅の対称性が崩れる可能性が高くなりがちなわけで。 以下、ギャラリー向けモードで。 >> 基礎を押さえれば 基礎を押えない人が多すぎて困ります。 ...って私も押えてない基礎が他人から見ればあるのでしょう多分。 でもそれは自分にはわかりません。 あったら指摘してください。...よろしく。 # 直せないことがあるかもしれません。(^^;; >> そして，「資源確保は初期設定」というC++の基礎を押さえれば， >> リークの可能性は相当減ると思いますが。 そう。 しかし、全てのデベロッパがそうしてくれるわけではないので。 具体例： デストラクタで資源解放 -> try-throw-catch の不正な使用でリーク。 CoTaskMemFree() し忘れ。 Detach() と Empty() の混同。 FindClose() 忘れで、ディレクトリを消せない。 リークする既成の dll を呼び出し、自分のリークだと思い込む。 同じ dll を何度も load ハンドルの上書き作成 エラーハンドリングの書き忘れ。 ＃ふう、枚挙にいとまがない。 API仕様をちゃんと読まずにコーディングする。 仕様書にうそが書いてある。 そもそも言語仕様をわかっていない。 仕様書があとからできる。 仕様が気分しだしでころころ変えられる。 コーディング担当者がころころ変わる。 プロジェクトマネージャがころころかわる。 いいかげんな引継ぎ。 他人のコードの誤読。 他人に誤読させかねないトリッキーな記述。 標準的な高速化コードにけちをつけてかえって変なコードにする。 飛ばしたメッセージが何段ものクラスを経て目的のクラスに到着する。 デバッグ中のコードを他人が持ち出し。 自身過剰な人がプロジェクトをひっかきまわす。 協調性のないひとが暴走する。 別プロジェクトでテストして組み込むべきものを主プロジェクトでテストを行う。 現場にテストを持ち込む。 再現性がない。 納期後デバッグ。 後日差し替え。 英語は読まない。 過去の技術に固執する。<- .... ひと事じゃないか .... 聞きたくないよね。こんな話。 _( O )_ ★メモリリークとの熾烈な戦い とは マルチスレッドができるとなると、 マルチスレッドのリークデバッグの仕事がくるかもしれません。 ということで。 人月100万はふっかけてやりましょう。 それも、納期不定で。 # 趣味ならいいのさ、お気楽で。 体悪くするよ、ほんとに。 (鬱);;