5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

リソースリーク対策

1 :デフォルトの名無しさん:2001/08/07(火) 20:12
普通のメモリリークなら、VCとかに標準でついてくる
チェック機能でかなりの部分を発見できるけれど、
GDI等のリソースリークはどのようにチェックしていますか?

NumegaやRationalのツールを使えばわかるけれど、ライセンス高価だし、
手軽に出来て、効果が期待できる方法ってないでしょうか

2 :デフォルトの名無しさん:2001/08/07(火) 20:15
MFCだったらラッパクラスを作って何とかなるよね。
でも普通にハンドルをやりとりしている部分は必ず出るし、
そういう所のチェックにいい方法はないのかなぁ

ハンドルをスマートポインタで実装……とか考えたけど、
よく考えればハンドルって32bitの整数だしなぁ

3 :トリッキーの1:2001/08/07(火) 20:21
APIラップを作って、ハンドルの生成と破棄を追跡すれば……

しかし全てのGDI関数についてAPIラップを作るのは骨が折れるな。
生成と破棄が絡む部分だけでいいんだけれど、SelectObjectとか
死にたくなるほど大変だ。

……大体、APIのラップってどうやって作るんだ?
#define CreatePen MyCreatePen
とかやったりしたら、
CPen::CreatePen
とかで死亡するし。

勢いだけで書いて自己完結してしまった

4 :トリッキーの1:2001/08/07(火) 20:49
自己レス。つーことは、APIをフックすればいいわけか。
しかしその場合、外部プログラムで記述するしか方法が無くなるな。
そうすると、ようやくメモリリークが見つかったとしても、
どこで起きたのか特定することが出来なくなるな。デバッグが大変だ。

どなたか優秀な方、
自分自身の呼びだすWindowsAPIのフックの方法を教えて下さい。

5 :デフォルトの名無しさん:2001/08/07(火) 20:54
APIと同じ関数の名前を含むDLLを別に作って、その
インポートライブラリを作えばいいじゃん

6 :トリッキーの1:2001/08/07(火) 21:05
なるほど、で独自DLLの内部で普通にfunctionコールをすれば
いいわけですか。なるほど、確かにそうだ。

VC++ならgdi32.libを使用しなければいいわけですね。
使用しない関数は全部丸投げすればいいわけですし……

ちょっと実験してみよう、ナイス助言サンクス

7 :デフォルトの名無しさん:2001/08/07(火) 21:39
そういう話ってdelphiとかだと殆ど聞いたことがなくて、
VC方面でばかり聞くんだけどさ(笑)、
つまりこれは出来がよい(この場合はリソースリークの少ない)クラスライブラリの
有無の問題であるわけっすか?

ラッパー層は、必ずしも薄くしないとパフォーマンスが(有為に)下がる
とは言いきれないし。

誰か、ばしっと、マシなライブラリを作らない(作れない)んですか?

8 :デフォルトの名無しさん:2001/08/07(火) 21:43
>>7
たしかにVBやDelphiやC++Builderではきかないね。

VCLはリソース管理は徹底してるしMFCみたいにユーザに
SelectObjectとかをいじらせてないな。

9 :トリッキーの1:2001/08/07(火) 21:47
>>7
リソースリークはWindowsの責任ですね。
言語の優劣は別スレの方が良いと思います。

10 :デフォルトの名無しさん:2001/08/07(火) 22:22
>>7
MFC というより、Win32 API を直接叩くかどうかの差だね。

直接 Win32 API を使うなら、必然的にリソース管理はプログラマの側
に降ってくるし(代わりにプログラマの自由度があがる、速度はいまど
き大差ないかも)し、API を一切使わせずにクラスライブラリのフレー
ムワーク内で対処するならリソース管理はクラスライブラリの責任にな
る。

それと、どうも Delphi ユーザの一部に、いちいち無関係なスレッドに
出てきて VC ユーザに喧嘩を売るような口調で書き込む人間がいるんだ
けど、荒れるからやめてほしいな(もしかして C++ で template 使
うとコード量が爆発するとか言ってたのと同一人物?)

11 :デフォルトの名無しさん:2001/08/07(火) 22:33
検査ソフトの性能がよすぎてライブラリのリーク情報てんこもりってことはないんですか?

12 :デフォルトの名無しさん:2001/08/07(火) 22:42
ライブラリのリークって何??
後、>>5の言っている意味はわかるけれど、
どうやってやるのか知りたい

13 :トリッキーの1:2001/08/07(火) 23:16
はまりました。
インポートライブラリを外から作るのが難しい。

VCなんですが、例えば
__declspec(dllexport)
HPEN __stdcall MyCreatePen(...){MessageBeep(0);CreatePen(...);}
というものを作って、DEFファイルで
EXPORTS CreatePen=MyCreatePen
とやって、フックされる方でgdi32.libを読み込まず作ったlibを指定しても、
リンクで外部参照のエラーが発生します。

libを見たところ、exportはちゃんとされてるっぽいんだけれど……
眠いので続きは後でやろっと。

もしものすごい間抜けな事をしていたら、誰か突っ込んで下さい。
dllまわりはほとんど知識がないので、是非是非

14 :デフォルトの名無しさん:2001/08/08(水) 01:28
>>11
昔あったらしいね。Winで。

15 :デフォルトの名無しさん:2001/08/08(水) 02:46
>>10
というか、MFCでもなく、かといってアプリ作成個人(または法人)が
毎回作るでもない、というクラスライブラリを、
誰かサードパーティ(商用かFREEかは別として)が作ったりした実績は
無いものなんでしょうか?

MFCはあんまり高級じゃないと聞くけど、
じゃあ誰かが作った高級ライブラリをその上にかぶせて、
そいつがデファクトスタンダードになったり、とかは
しないものなのかな、と。

>C++ で template

ああ。あれ?厨と一緒にせんで。

16 :8:2001/08/08(水) 03:28
俺C++ Builderユーザだけど喧嘩売るつもりはないっす。
ただ、プログラマの労力を軽減するのがフレームワークであり、
クラスライブラリでしょ?ってことで。

17 :デフォルトの名無しさん:2001/08/08(水) 04:22
車輪の再発明無限地獄

18 :デフォルトの名無しさん:2001/08/08(水) 08:34
WinAPIのフックに別アプローチで成功

しかしスレの趣旨とずれ始めているので深く書くのはやめておきます。
知りたい人もいないだろうし。

19 :デフォルトの名無しさん:2001/08/08(水) 11:08
BoundsCheckerとかPurify使えば? (金があるなら)

20 :デフォルトの名無しさん:2001/08/08(水) 18:32
>>19
1をよく読もう

21 :デフォルトの名無しさん:2001/08/08(水) 22:56
Del厨が来ると雰囲気が悪くなる定説

22 :デフォルトの名無しさん:2001/08/09(木) 02:04
>21 オマエモナ

>1
>普通のメモリリークなら、VCとかに標準でついてくる
>チェック機能でかなりの部分を発見できるけれど、
これってなんのこと?

23 :デフォルトの名無しさん:2001/08/09(木) 02:12
デバッグ版の CRT には、ヒープの使い方を追跡する機能がある。

デフォルトではメモリブロック識別子しか有効にならないんだけど、フ
ラグを設定すれば malloc(), free() 時にヒープが壊れていないかチェ
ックしたり、プログラム終了時に解放されていないメモリ領域をダンプ
できます。

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF);

私がプログラムを書くときのデフォルトは↑こんな感じ。

24 :22>23:2001/08/09(木) 02:22
そんな機能があるなんて知らなかった。ありがと。
つっても最近Visual StudioでPerlとRubyしか書いてないけど(藁

25 :トリッキーの1:2001/08/09(木) 23:12
APIのフックには成功、単体exeなら
GDIまわりのハンドルの移動を大体掴むことが出来ました。
解放し忘れのGDIObjectをちゃんと表示できます。

しかし、DLLとかが絡んでくると厄介。
例えば、sample.exeはgdi32.dllとoriginal.dllとmfc42.dllをインポートしているとして、
とりあえずここのgdi32.dllをフックしたとしても、それだけでは足りなくて
mfc42.dllにインポートされているgdi32.dllもフックする必要があるし、
もしoriginal.dllがmfc42.dllとgdi32.dllをインポートしていたら……

とか考え出すと、全部にフックをかけるだけで果たしていいのか不安になります。

ま、暇な時に続きを作ってみます。

26 :デフォルトの名無しさん:2001/08/09(木) 23:21
_inmm.dllがやってるようにexeのインポートエリアを書き換える、
という方法もある。
これ使ってkernel32.dllをオーバーライドして日付を狂わし、
シェアウェアの使用期限を延ばす、なんちて。

27 :トリッキーの1:2001/08/09(木) 23:25
>>26
過去レスにもあったけれど、その場合って
GDI32.DLLを完全にサポートした疑似DLLが必要になるんじゃないですか?
(もちろんインターフェースだけで、内容は本物にまわせばいいわけですが)
それを作るならフックの方が早いかな、なんて思ったり

28 :デフォルトの名無しさん:2001/08/09(木) 23:32
Windows互換のオプソなOSをハクる

29 : :2001/08/09(木) 23:33
>>25

自分で作るexeとdllに全てそれぞれ内部でフックさせればいいのでわわわ?

30 :トリッキーの1:2001/08/09(木) 23:39
例えばMFC共有DLLを使っていた場合、
その共有DLLの内部でGDIリソースリークが起こったら問題がおきるのでは?

CBrush *p=new CBrush(RGB(0,0,0));
delete p;

みたいな。

31 : :2001/08/09(木) 23:53
>>30

CBrushのデストラクタで開放してくれているんじゃないの?
まぁSelectされたままでは出来ないのかも知れんが。

最悪でもCDCとCBrushの派生クラスを作ってチェックすればいいと思います。

32 :デフォルトの名無しさん:2001/08/09(木) 23:53
>>28
ハクるってなによ?
ヴァカじゃねーの!(ワラ

33 :トリッキーの1:2001/08/09(木) 23:58
>>31
ああ、確かにこのコードだとデストラクタが呼ばれるか。
deleteが無ければ……メモリリークか(笑)
何にしても、言いたいのはMFCについてではなく、
自分の作ったEXEやDLLだけフックしても完全では無いぞ、と言うことです。

派生クラスの話をしたら、ハンドルをスマートポインタで実装したら
すべて解決してしまうので、ここでは既にある巨大なソース群に対し
簡単にチェックする方法を考えてみましょう。

34 :デフォルトの名無しさん:2001/08/10(金) 00:07
>>28

WINEとかReactOSとかかな。Reactはおいておいて、
あれはそれ以前にその環境でアプリをまず動かすように
するほうが大変かな。
でもWINEとかでVisualC++が動いているのをみるとあながち
不可能ではないかも。
Windowsに標準でリソースリークの警告機能ぐらいあっても
よいのに・・・デバッグ版windowsではあるのかな?

>>32

まぁわかんない人には永遠にわかんないでよい言葉だ。

35 :デフォルトの名無しさん:2001/08/10(金) 00:52
Windowsに標準で警告機能があったらさぞかしウザイだろうなぁと今思っ


たしかにアプリが解放しないで終了したリソースはOSが解放しなければならない
ってのはそうなんだけど、それをアテにするべきかは、、、って
この話題はやめておきましょうか。なんか他のスレであれているのを
見たような気がする。

36 :デフォルトの名無しさん:2001/08/10(金) 01:24
>>35
一度走ってすぐ終了するプログラムなら、
リソースの解放なんてしなくてもいいと思うんだけども。
makeとか。

37 :デフォルトの名無しさん:2001/08/10(金) 01:30
98以降なら結構OSで解放するよ

38 :デフォルトの名無しさん:2001/08/10(金) 03:14
gc付ければ?
最悪還元時にfinally起動するとか。

39 :デフォルトの名無しさん:2001/08/10(金) 09:27
>>35,36
この話題って、fj.comp.lang.cの恥さらしネタだな(藁
アプリが終了後に「OSが」責任もって食べ残しを始末してくれるタイプの餌については
それ(>>36)でいいって奴。現にそれが達成されてないOSでやらなきゃならない仕事が
有るならば、別の手段…つまり厳密な解放の策を講じないとならん。

>>38
某GCライブラリをあてにしてたら、終了時に残ったものが解放されなくて焦った(藁
終了の直前までは領域を指すポインタが生きてる(Global変数とかなら特に)からGCされないし、
終了しちゃったらそもそもGCもへったくれもない。
結果として解放するチャンスがない(藁

結局この問題にとって必要なのは、例外というよりもfinallyつまり後始末の仕掛け(だけ)。
もちろん、プログラム動いてる「途中」のものを解放させるためにはGCは効果的だが。

WeakPointerを持ったCollectionに結び付けておいて、at_exitで明示的解放をさせる、
とかをすれば有効かな。

40 :デフォルトの名無しさん:2001/08/10(金) 09:31
Windowsで食べ残しをOSが始末してくれないものって何かありますか?

41 :デフォルトの名無しさん:2001/08/10(金) 12:45
なんかワケ分からんのが出てきたな(藁
Windows環境でのリソースリーク対策の話をしているのではないの?

42 :デフォルトの名無しさん:2001/08/10(金) 12:52
>>40
95や95OSR2の時代はWinsockやRAS絡みであったらしいけど、今特に目立つものは無い。
よって39の仮定はもはや意味なし。39は巣に帰りましょう。

継続的な動作をするプログラムでのリソースリーク対策
ならば、有益な話が期待できそう。

43 :デフォルトの名無しさん:2001/08/10(金) 15:13
>>40
タスクトレイのアイコンとかかな。
でも仕様って逝ってしまえばそれまでかもなー

44 :デフォルトの名無しさん:2001/08/11(土) 00:23
>>43
タスクトレイにアイコン突っ込みまくるプログラムを作れば
そのうちExplorerが落ちるってことですね。チャレンジしてみます。

45 :デフォルトの名無しさん:2001/08/11(土) 00:31
自分で自分を起動する常駐アプリを作れば一瞬でわかります(藁
間違ってやったら途中で(120個位)起動できなくなった覚えあり(Win2000)

46 :トリッキーの1:2001/08/11(土) 01:11
エクスプローラを落としたいならいくらでも方法があるだろうに(笑)

さて、面白い事を発見。Win9X系では、DeleteObjectの挙動が不穏です。
この関数は成功すればtrueを返すんだけれど、例えば
....
SelectObject(hMemDC,hBitmap);
....
BOOL b=DeleteObject(hBitmap);
ReleaseDC(hDC);
とかやると、ここでhBitmapの削除に失敗し
リソースリークが発生するにも関わらず、
なぜかb==1になってしまうのです。

と言うわけで、Purifyでも検出出来ませんでした(元々NT用だから話が違うけれど)。
これを検出するにはどうすればいいんだろう?

……今思いついたが、2回DeleteObjectをやってみるのは手かも知れない。

47 :デフォルトの名無しさん:2001/08/11(土) 01:19
>>46

不穏なのは既出

http://www.microsoft.com/JAPAN/support/kb/articles/J024/2/17.htm?LN=JA&SD=SO&FR=0

> Windows 95 では、SeleteObject() で DC に選択されているときに GDI
> 描画オブジェクトを削除しようとすると DeleteObject() への呼び出しが
> 正常終了します。
>
> しかし呼び出しが正常に終了しても実際には削除されていません。Windows NT
> では DC に選択された GDI オブジェクトで DeleteObject() への呼び出しを
> 行うと失敗します。 DeleteObject を呼び出す前には GDI オブジェクトの
> 選択を常にクリアする必要があります。

48 :トリッキーの1:2001/08/11(土) 01:53
既出でしたか、失礼&情報源多謝
じゃ、NT系列でDeleteObjectの正否をチェックするか、
9xでDeleteObjectの複数成功をチェックするか、どちらかですね。

普通メモリリークを追跡する場合の開発環境は9x系列のはずなので、
後者の方向でチェックツール開発を進めてみます。

49 :31:2001/08/11(土) 10:50
>トリッキーの1

既にある大量のソース群ですか...
だったらマクロ使って自分で作った派生クラスを通すようにするのじゃダメ?
例えば、
#if _DEBUG // デバッグ時のみチェック
#define CDC CUserDC
#define CBrush CUserBrush
#endif
とする。

そんでCUserDCでどのオブジェクトが選択されているか、CUserBrushで
どのDCから選択されているかを記録しておく。
そうすればDCを開放する時に選択済みオブジェクトがあれば、非選択にした後に
開放できるんじゃないかと思った。

どうでしょう?

補足:DeleteObject()の戻り値を確実にチェックしておけばリークが見つかるんだけどね。

50 :トリッキーの1:2001/08/11(土) 23:17
>>49=31
それだと、MFCにしか対応できないので辛いのですよ(参照>>2氏)
完全にMFCしか使っていなければ、もちろんそれで可能なのですが。

51 :デフォルトの名無しさん:2001/08/11(土) 23:30
Javaを使えばリークしません。よくわかったか愚か者ども!!

52 :デフォルトの名無しさん:2001/08/11(土) 23:31
ようわからんがタスクマネージャのGDIオブジェクトの値を見ときゃいいんか?

53 :デフォルトの名無しさん:2001/08/11(土) 23:32
>>51
ハイハイ、自分の技術力の無さを認めたわけね。
ある意味潔くていいよ。

54 :!!!警告!!!:2001/08/11(土) 23:32
〜java厨房徘徊中〜

55 :デフォルトの名無しさん:2001/08/11(土) 23:35
やってることはあんまり変わらんぞ>54<オレモナー

56 :トリッキーの1:2001/08/11(土) 23:44
>>52
やはり当然、オンザフライで警告を出したい。

>>51
マジレスすれば、C#を使えばこの種の問題は無くなる。
しかもJavaのように速度がネックになることも無い。
しかし汎用性は無くなる。まぁこの場合Windows特化なので
汎用性は話の外だからいいけどね

57 :デフォルトの名無しさん:2001/08/11(土) 23:46
C#なんてJavaの下の下。比べ物にならない。

58 :デフォルトの名無しさん:2001/08/11(土) 23:56
57なんて"トリッキーの1"氏の下の下。比べ物にならない。

59 :デフォルトの名無しさん:2001/08/11(土) 23:59
>>51
サーバサイドで Singleton のコレクションにオブジェクトがんがん
突っ込んで削除しない VB 厨房上がりが多いんだが。

60 :デフォルトの名無しさん:2001/08/12(日) 00:03
58なんて57氏の下の下。比べ物にならない。

61 :デフォルトの名無しさん:2001/08/12(日) 00:36
ジサクジエンミグルシイ

62 :デフォルトの名無しさん:2001/08/12(日) 00:41
どうも、Java厨です。

Javaって、streamのclose()を呼び忘れてると、finalizeされるまで
システムリソース(fdやsocket)を握ったままになりますね。マヌケです。
強制GCすればいいんですが、GCでfinalizeされるとは規定されてないし、
結構厄介だと思います。だけどJava最高!!!

63 :デフォルトの名無しさん:2001/08/12(日) 00:45
スレの方向性がずれまくり

というわけで、案外API拡張はまともなアイデアかもしれません
しかしモジュールごとにフックする必要がなぜあるのかわかりません。
APIって皆同じコードが呼ばれているんじゃないの?

64 :デフォルトの名無しさん:2001/08/12(日) 00:46
ジサクジエンミグルシイ

65 :デフォルトの名無しさん:2001/08/12(日) 05:44
メモリーリークの対策をプログラマーがやらないといけない言語なんて
もう古いよ。

66 :デフォルトの名無しさん:2001/08/12(日) 08:34
メモリーリークっつうかリソースリークの話題だけどな。>>65

67 :31:2001/08/12(日) 08:40
ええい、WinAPI用だと以下の対策でどうでしょうか?

#if _DEBUG // デバッグ時のみチェック
#define SelectObject UserSelectObject
#define DeleteObject UserObjectDC
#define DeleteDC UserDeleteDC
#define ReleaseDC UserReleaseDC
#endif

あとはCreatePenとかのオブジェクト作成関数もラッパすれば完全では?

つか、この手のものは1本ソース書いておけばいろんなプロジェクトで使いまわしできるんだし、
身の回りの誰かが作っていたりして。

68 :トリッキーの1:2001/08/12(日) 09:03
>>67=31
それだと、
CDC *pDC;
..
pDC->SelectObject(hBrush); // アウト

69 :デフォルトの名無しさん:2001/08/12(日) 09:11
どうも、Java厨です。

>>66
ええ、そのとおりです。メモリーリークでなく「リソース」リークですね。
実行中のリソース解放し忘れは、Javaであっても鬼門なんです。
なんせgc/finalizeの実装に依存しちゃいますからね!でもJava最高!

70 :デフォルトの名無しさん:2001/08/12(日) 12:42
2年目の JDBC ほとんどやったことない奴が中途半端なDBアクセス
のスーパークラスを作ったおかげでリソースリークでまくりです。
30 分も動かしているとアプリケーションとまっちゃいます。
うんこ。






                              うんこ。

71 :70:2001/08/12(日) 12:45
アプリケーション → アプリケーションサーバ
ひどく疲れているようだ...

72 :デフォルトの名無しさん:2001/08/12(日) 23:33
>>71
どちらかというと> うんこ。を二つも書く辺りに取り返しのつかない疲労を感じる

73 :デフォルトの名無しさん:2001/08/13(月) 03:25
>>67
CUserDC:CUserSelectObjectになっちゃいます

この方向のアプローチはデバッグ版ではリークしないのにリリース版で
リークするという現象が発生したときどうにもならないし

74 :デフォルトの名無しさん:2001/08/14(火) 00:03
ところで

>>56 (C#)
>しかもJavaのように速度がネックになることも無い。

これ本当ですか?何故そうなるっすか?Javaとそんなに違うっすか?

75 :デフォルトの名無しさん:2001/08/14(火) 06:31
>>74 嘘に決まってんだろ。Java よりも速いと歌ってのはまだモノも出来てない
話題沸騰中の頃のセールストークだよ。それを信じたまま今日まで来てる C/C++
信者多すぎ。

76 :デフォルトの名無しさん:2001/08/14(火) 08:36
>>75
C/C++信者 → MS信者

Javaの、まだモノも出来てない話題沸騰中の頃のセールストークも酷かったねえ...

77 :デフォルトの名無しさん:2001/08/14(火) 08:45
C#はJavaより低速だよ。Javaのほうが歴史が長い分最適化されてる。

78 :トリッキーの1:2001/08/14(火) 09:11
なんか、俺のC#の認識がずれてる気がしたので、
スレ違いだけれどちょっと確認させてください。

セールストークとβ版によれば、
・VMを介しないのでコードが高速(利点)
・標準ライブラリが充実(必須)
・ネイティブコード依存(欠点)
なので、クロスプラットフォームが多少関わるWeb系は今まで通りJavaで、
Windows系のGUIプログラムはC#に移行していく、と思われます。

Javaを使い続ける限り、どんなにCPUが高速になったところで、
速度で「VMを介する」というネックを避けることが出来ないので、
Windowsネイティブに限ればC#で開発するメリットは非常に大きいでしょう。
しかし、速度よりも移植性が大事なWeb系のプログラミングでは、
IISでしか使えないであろうC#にわざわざ乗り換える人も少ないでしょう。

(仮にLinux上などで環境が整えば、一気にC#の価値が高まるでしょうね)

コレについて、具体的に「この点が違うよ」というのがあれば教えてください。
この話題についてはsage進行でいきませう。

79 :ななC#:2001/08/14(火) 10:32
>>77
最適化については、直感的にC#の方が優れているような。
言語の歴史では明らかにCの方が長いし、
C#とJavaは同じ最適化理論を使える(オブジェクト言語最適化)し、
歴史的にMSは開発環境だけはいいものを提供してくれるし。

C#が低速というのは、実験した結果?だとするとそうかもしれないけど。
ま、製品版がリリースされるまで解らないな

80 :デフォルトの名無しさん:2001/08/14(火) 10:46
>>78
> ・VMを介しないのでコードが高速(利点)
CLRってのはVMだろ。

81 :トリッキーの1:2001/08/14(火) 10:56
CLR知りませんでした。
こんな知識でC#について語る資格はありませんね。
ごめんなさい。

しかしまぁ、Javaの様な汎用的なVMではなく、
Windowsに特化したVMして速度改善を達成するのでは、と
思われるのですが、その情報をご存じの方は?

というか、やっぱりC#はC#スレでやるべきですね。
このスレで不用意なC#の発言をしてしまい、結果荒らしてしまいすみません>1さん

82 :31:2001/08/15(水) 01:06
>>68
MFCじゃなくてAPIの場合の話だったのに...
ちなみに「漏れなくラッパする」って考え自体がまずいの?

>>73
デバッグ版とリリース版で動作が違う時ってどんな場合があったっけ?
変数の未初期化での使用とか配列でちょっとオーバーして使った場合とかは経験あるけど。
まぁそういうのはツール使えば発見できるんだけど、それじゃぁ本末転倒だし。

83 :トリッキーの1:2001/08/15(水) 10:23
>>82
そうじゃなくて、そんなdefineをすると、
APIじゃない部分でコンパイルが出来なくなるよ、ということ。
完全MFC or 完全APIで書かれていたら問題はないけれど、
両者が混在している場合も十分考えられるでしょ?

もれなくラッパ出来るならば一番いいんだけれど、
多分API自身をラッパする以外の方法では無理だと思われます。

84 :31:2001/08/15(水) 11:53
>>83

なるほどねー
まぁチェックルーチンを後付けだとうまく行かない部分もあるかも。
理想的には開発時にチェックルーチン付けちゃえば問題ないんだけど。

85 :トリッキーの1:2001/08/15(水) 13:20
開発時にチェックルーチンを付けるなら、
所有権付きのスマートポインタもどきでハンドルクラスを実装すると
結構うまく行くんじゃないのかな?
その場合の所有権は、DCに対応する感じで。
誰か既に作ってそうだけれど、ご存じの方は?

86 :デフォルトの名無しさん:2001/08/17(金) 00:45
安芸

87 :デフォルトの名無しさん:2001/08/17(金) 02:56
>>85
すでにチェックを行うためじゃなくてそれで管理行っちゃった方がよいと思うが

88 :デフォルトの名無しさん:2001/08/18(土) 03:58
BoundsCheckerもどきを自作する

89 :デフォルトの名無しさん:2001/08/20(月) 11:50
結局、リソースのオーナをしっかり決め、管理する仕掛けが必要って事だな

90 :デフォルトの名無しさん:2001/08/20(月) 17:45
>>56
いまさらで悪いんですが、C#ならリソースリーク防げるってのは、
VCLを使えばリーク防げる/VBを使えばリソース管理を気にする必要がない、
と言うのと同様の問題を含んでません?

APIを使うって事は、要はその開発環境の標準ライブラリだけじゃ実装しきれ
ない状況に追い込まれて仕方がなく使用するわけだから、C#になっても、結局
は(ポインタ使用可能なモードにしての)ポインタの管理、或いはそれに準ず
る問題に行きつく気がするんですけど。

91 :デフォルトの名無しさん:2001/08/21(火) 00:07
>>90
実際ソノトオリ行けるかどうかは別として一般論に過ぎないが、
JNIやポインタ使用可能モードなC#やrubyの拡張ライブラリ(藁)みたいなものが
うまくいくかどうか?は、それらのクラスライブラリが拡張ライブラリに対して、
いかにハマリ「にくい」モデル(Frameworkといってもいい)を提供してくれてるか?に
かかっている、という面が有るように思える。

標準ライブラリが無ければ常に丸裸だ、というほどまでに
プログラミングの世の中は冷たくもなければAllOrNothingでもない。
というか、そんなつかえねぇ環境は滅びやがれってかんじ。

フレームワークっていう考え方が重要だよ。
ライブラリといわば逆の考え方。
ライブラリは他人が作ったサブを自分が作ったメインが呼ぶ。
フレームワークは自分が作ったサブを他人が作ったメインが呼ぶ。

92 :デフォルトの名無しさん:2001/08/21(火) 07:23
VCLにしても、
APIで欲しいリソースをVCLから貰うという方法でリークはだいぶ防げる筈

93 :デフォルトの名無しさん:2001/08/21(火) 21:28
リソースリークとメモリリークを混同していいものか・・・

94 :デフォルトの名無しさん:01/08/26 21:36 ID:SM0Vd3m6
保存sage

30 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)