もちろん、リークはバグですし直すべきです。
ITRON等のようにケアしてくれないOSもありますし、
終らない限りだだ漏れですし。
ただWindowsのような昨今の高級OSでは、
「プロセス自体が終わる」のなら、
その時にOSが、そんな駄目プロセスのせいでOS自身や他のプロセスまで
おかしくならないように、わりあててあげてた分を全部取りあげます。
メモリやハンドルはOS管理なので貸してた量はわかりますし。
ただし使い方には関知してませんから無視して破棄されます。
外部リソースもどう使ったか関知してませんので同様です。
これらの終了処理は無視されると一般に危険です。
#自発的にきちんと返さないと怖いおにいさんの取り立てが来る、と。
> おかしくならないように、わりあててあげてた分を全部取りあげます。
> メモリやハンドルはOS管理なので貸してた量はわかりますし。
なるほど、デバック時にでるメモリーリークのダンプ表示は、OSで処理されます
という警告でもあるのですね。
>#自発的にきちんと返さないと怖いおにいさんの取り立てが来る、と。
そうですね、正常終了に越したことないですね。
その警告自体はVCのデバッグ版ライブラリが出してますから(VCのCRT付加機能)、
まだブロセス内の話で、また別ちょっと違った立場だと思いますが、
(怖いおにいさんが来る前に、心配してくれる親?)
その後OSに(無言で)捨てられるので、まぁ見た目の結果は大差ないですね。
スレッドを使う上でメインスレッドからワーカースレッド等のサブスレッドを
安全に終わらせる手段まで考慮する必要があるという事を認識してスレッドを
使用していない方が結構いらっしゃるみたいです。
結果的にOSが後始末をしてくれるとは言っても、本来はプログラムの開始から
終了までの処理はプログラム側で責任を持って行うべき物ですし、
OSの後始末をする機能は、最悪の事態でもシステム全体への影響を最小限にする為の
物と考えるべきだと思います。
ワーカースレッドが動作中にメインスレッドを終了させるような場合に
安全にワーカースレッドを終了させる為の仕組み等々は設計の時点でちゃんと
考えておくべきだと私は思います。
うわー、わかりにくいので修正。
> スレッドを使う上でメインスレッドからワーカースレッド等のサブスレッドを
> 安全に終わらせる手段まで考慮する必要があるという事を認識してスレッドを
> 使用していない方が結構いらっしゃるみたいです。
スレッドを使う上でメインスレッドからワーカースレッド等のサブスレッドを
安全に終わらせる手段まで考慮する必要があるという事を認識しないで
スレッドを使用している人が結構いらっしゃるみたいです。
>PATIOさん
御意。
外部リソースの面倒とか見てくれませんし。
> Banさん、ITOさん、PATIOさん
いろいろ勉強になりました。
http://rararahp.cool.ne.jp/cgi-bin/lng/vc/vclng.cgi?print+200607/06070042.txt
のすれで、
Blue 2006/07/14(金) 17:53:04
> CEditのポインタでなく、エディットボックスのウィンドウハンドルでSendMessage
> する方法でやったほうがよいでしょう。
> (CEditのポインタだと、ダイアログスレッドが終わるとアクセスできなくなる。
> スレッドになる以上こういう状態はありうる)
と書いたんですが、親が子をきちんと管理すれば、このような考えはしなくてもよかっ
たのですね。
(というか、こういう状態にはなりえないということですよね?)
>と書いたんですが、親が子をきちんと管理すれば、このような考えはしなくてもよかっ
>たのですね。
>(というか、こういう状態にはなりえないということですよね?)
親のthisポインタを取得してそこからCEditのポインターを得れば大丈夫だと思うの
ですが、CEditのポインターだと心配が残りますね。
基本的には互いにアクセスする必要がある時点で全てのスレッドの寿命は
きちんと管理されている必要があります。
メインスレッドはサブスレッドの生き死にをきちんと把握しているべきですし、
サブスレッドからメインスレッドに何らかの通知を行う場合は、
サブスレッドが生きている間はメインスレッドがきちんと生きている保障を
するべきです。
あと、スレッドを跨いだCWndオブジェクトのやり取りはMicrosoftが公式に
してはいけないと書いていますからするべきではありません。
基本的には親スレッドのウインドウハンドル宛にユーザー定義メッセージを
送ってメインスレッド側で画面側の更新を行うとかするべきでしょう。
基本的にウインドウメッセージを使ったやり取りにした方がスレッド間も
疎結合になるので良いと思います。
補足。
> あと、スレッドを跨いだCWndオブジェクトのやり取りはMicrosoftが公式に
> してはいけないと書いていますからするべきではありません。
現在のMFCの実装をソースで確認して大丈夫だから使えるとおっしゃる方も
いますが、基本的には公式にしてはいけないと書いている事をすべきではありません。
これは、Microsoftが今後実装に変更を加えて出来ないようにしても
公式見解と矛盾が無いのでわれわれから文句を言う余地が無いという事を含んでいます。
今、使用できる実装になっていても今後その実装が保障されていないのであれば
使用するべきではありませんし、他の人に進めるべきでもないと私は考えます。
がーっ、誤字
誤)
> 使用するべきではありませんし、他の人に進めるべきでもないと私は考えます。
正)
使用するべきではありませんし、他の人に勧めるべきでもないと私は考えます。
>あと、スレッドを跨いだCWndオブジェクトのやり取りはMicrosoftが公式に
>してはいけないと書いていますからするべきではありません。
HWND = NULL の例外で何度も悩まされました。
http://rararahp.cool.ne.jp/cgi-bin/lng/vc/vclng.cgi?print+200607/06070042.txt
スレでやろうとしているのが、「SetWindowsText」による値の書換えなので
問題ないと思ったのですが........
もちろん、ウインドウのサイズ変更・色の変更・位置の変更等のウインドウ自身の
操作に関することは、メッセージ等で親ウインドウに知らせて親ウインドウで行わない
といけないと思います。
>今、使用できる実装になっていても今後その実装が保障されていないのであれば
>使用するべきではありませんし、他の人に勧めるべきでもないと私は考えます。
そうですね。今後気をつけます。
> スレでやろうとしているのが、「SetWindowsText」による値の書換えなので
> 問題ないと思ったのですが........
> もちろん、ウインドウのサイズ変更・色の変更・位置の変更等のウインドウ自身の
> 操作に関することは、メッセージ等で親ウインドウに知らせて親ウインドウで行わない
> といけないと思います。
内部的にはSetWindowsTextもウインドウのサイズ変更もたいして変わらないと思いますよ。
SetWindowsTextにしても、内部ではSendMessageで そのコントロールのHWNDにWM_SETTEXTを
飛ばしているだけです。
ある程度以上は個々人のポリシーも出てきてしまうのであんまり押し付けてしまうのも
不味いかもしれませんが、基本的にダイアログ内の操作はダイアログ内で完結した方が
ソースを追いける場合でもわかりやすいと思います。
サブスレッドはダイアログに対して特定の場所を引き渡した文字列で更新する事を
依頼するだけにして実際の更新はダイアログ側が行った方が機能の切り分けとして
すっきりしていると私は考えています。
あがが、
SetWindowsTextではなくてSetWindowTextですね。
>あがが、
>SetWindowsTextではなくてSetWindowTextですね。
すみません、こちらが先に間違ってました。
>内部的にはSetWindowsTextもウインドウのサイズ変更もたいして変わらないと思います
>よ。
>SetWindowsTextにしても、内部ではSendMessageで そのコントロールのHWNDに
>WM_SETTEXTを
>飛ばしているだけです。
なるほど、「SendMessage」をつかっているんですね。
直接変えているのかと思っていました。