トップページ⇒tech
1001コメント312KB

C++相談室 part63

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2008/07/26(土) 02:51:09
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。

前スレ
C++相談室 part62
http://pc11.2ch.net/test/read.cgi/tech/1211900039/
0153デフォルトの名無しさん2008/08/02(土) 18:37:59
>>152
正解。
0154デフォルトの名無しさん2008/08/02(土) 18:42:17
誰もつっこんでないが
＞int *p = vint[0];　//1のアドレス
これ、アドレスじゃなくて、要素の値を代入しちゃってる
0155デフォルトの名無しさん2008/08/02(土) 18:58:26
たんなるタイプミスだろそれは。
問題はそこじゃねーよ。
0156デフォルトの名無しさん2008/08/02(土) 19:09:55
　　　　　　　　　 __、
　　　　　,r´⌒ヽ,⌒ヽ,ヽ
　　　(⌒)､　　 .人　 λ＼､ .＿＿___
　　　 ＼. ＼　　　　、　ヽ.／ ー 　ー＼
　　　　 |＼　＼ 　 　ヽ.／　（ ●）　（ ●）
　　　　 |　 ＼　 ＼　／　　　　　（__人__） ＼　 はい、どーもすみませんでした
　　　　 |.　　 ＼　 　|　　　　　　　｀ ⌒´ 　　|
　　.　　 |.　　　|.＼_ノ＼ 　　　　 　　　　　　/
　　.　　 |.　　　|　　 | 　 ＼＿＿＿＿＿_／
　　.　　 |　　　)　　.|　 　　　.　.￣￣
　　.　　 |　　　|　　.|
　　　　　|　　 |.|　 .|
　　.　　　|　　| .|　.|
　　　　 ／ 　/ /　ヽ,
　　　　(＿_ノ　 ヽ、__つ
0157デフォルトの名無しさん2008/08/03(日) 10:27:47
>>152
「確実じゃない」というのがどの範囲まで指した言葉なのかによりますけれど，
コンテナ内への参照が無効化されるのを reserve で阻止するのは
きちんと扱うならば規格の保証の範囲内ですよ
0158デフォルトの名無しさん2008/08/03(日) 12:50:22
STLのstringについて質問です

void main()
{
　　_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);
　　std::string str("tekito");
　　str.append("namojiretu");
　　exit(-1);
}

上記のコードがメモリリークになるのですが、どうやって解決すればいいのでしょうか？
eraseやclearを使っても解決できません。
また条件が特定できなかったので明記しませんが、使う場所によっては文字列中に改行文字があったときだけ
メモリリークするような現象も起こりました。
解説よろしくお願いします
0159デフォルトの名無しさん2008/08/03(日) 12:57:23
C++ではexitを使わないこと。
0160デフォルトの名無しさん2008/08/03(日) 13:08:51
>>158
こんなんとか。
http://msdn.microsoft.com/ja-jp/library/8bsz08tx.aspx

_CRTDBG_MAP_ALLOC 定義した状態の出力を見れば、もう少し情報が増えるかもね。
0161デフォルトの名無しさん2008/08/03(日) 13:09:20
んじゃあ何で終了するんですか？
0162デフォルトの名無しさん2008/08/03(日) 13:11:31
mainから素直に抜けて下さい。
むしろ、int mainにしてreturnして下さい。
0163デフォルトの名無しさん2008/08/03(日) 13:12:24
exit(-1)の中でプログラムが終了・リークチェックが走る
strはスコープを抜けてないのでデストラクタが走らない。
0164デフォルトの名無しさん2008/08/03(日) 13:14:03
>>160
>Visual Studio .NET 以前のバージョンの標準テンプレート ライブラリは _CrtDumpMemoryLeaks が誤検出を報告する原因となっていましたが、最新リリースでは修正されています。
これ今現在は大丈夫ということなんじゃないんですか？
ちなみに使っているのはVS2005です。
0165デフォルトの名無しさん2008/08/03(日) 13:17:40
>>162
>>163

そうするしかないのかー
サブ関数とかで階層が深くなってるとmainまで戻してくのが面倒だったのでexit使ってたんですが…
うーん、直すしかないのか
0166デフォルトの名無しさん2008/08/03(日) 13:27:49
プログラム終了用の例外作って代わりにすればよくね？
main関数でcatchすること前提にすればギリギリ有りな気が。

struct exit_class{};
void exit_cpp(){
throw exit_class();
}

0167デフォルトの名無しさん2008/08/03(日) 13:30:48
>>166
すんません、アホでした
例外投げるという方法をすっかり忘れていました
ありがとうございました
0168デフォルトの名無しさん2008/08/03(日) 15:18:40
俺は何の躊躇もなくexit使ってるぜ。
組込みじゃないんだから、プログラム終了時のメモリリークなんてOSがなんとかしてくれるさー
0169デフォルトの名無しさん2008/08/03(日) 15:21:07
それでもリソースリークのリスクは依然としてある。
0170デフォルトの名無しさん2008/08/03(日) 15:44:26
そのexitがエラー時の終了じゃなく、通常の終了処理なら
それはプログラミングの怠慢だろ
スパゲティ風味がするぞ
0171デフォルトの名無しさん2008/08/03(日) 16:30:16
今さら人には聞けないシリーズなんですが、vectorとdequeってどう発音してますか？
vector：ベクトル？ベクタ？
deque：デック？ディーク？デキュー？
0172デフォルトの名無しさん2008/08/03(日) 16:33:45
>>170
俺のスパゲティはおいしいんだい！
リソース解放はatexit()で解放ルーチン登録してるからいいもん！


>>171
ベクターとデキューって心の中で発音してます。
0173デフォルトの名無しさん2008/08/03(日) 16:37:38
>>171
俺はデキューと読んでいるが、確かデックが正しい発音のハズ。
0174デフォルトの名無しさん2008/08/03(日) 16:41:22
http://d.hatena.ne.jp/yaneurao/about
プロフィールを詐称
「有限会社やねう企画 代表取締役」

だが、有限会社やねう企画は既に倒産している。
http://www.sia.go.jp/~osaka/zenso/19.09.pdf

また、このやねう企画代表者やねうらお
（本名・磯崎元洋　所在地・大阪府八尾市末広町２－１－２）は
１．労働契約上の不正行為を行っていた
２．他社製ソフトウェアの不正コピーを行っていた
３．不正コピーしていないことを証明しようとしてエロゲーのパッケージを発見し、
　写真に撮ってアップロードしようとした。
http://d.hatena.ne.jp/pmoky/19000106
やねう企画の裏側（競馬の詐欺ソフトの製作現場）
http://d.hatena.ne.jp/pmoky/20060510
http://d.hatena.ne.jp/pmoky/20060511
http://d.hatena.ne.jp/pmoky/20060512
0175デフォルトの名無しさん2008/08/03(日) 17:47:53
>>174
それもう飽きた。

>>172
exit()を使いたいがために登録し捲くるの?
個数制限もあるのに?
0176デフォルトの名無しさん2008/08/03(日) 18:21:38
int main try{
}
catch(...){
}

これ最強じゃね？
0177デフォルトの名無しさん2008/08/03(日) 18:45:18
>>174
弓月さん！！コピペなら俺も協力させてもらいますよ！！！









【自作自演】弓月城太郎氏に関するまとめ【神秘体験】
http://d.hatena.ne.jp/yaneurao/20080619
0178デフォルトの名無しさん2008/08/03(日) 19:12:04
実際、メモリーリークなんてプログラムが終了すれば、全部解放されるんでしょ？
Windowsなら。
0179デフォルトの名無しさん2008/08/03(日) 19:15:25
終了時に解放しないのは、低レベルなリソースだけでみれば、Windowsでは問題ないが、

しかしデストラクタが走らないので、
例えばデストラクタでファイルへの書き込みを行うだとか、
そういうことをしているとまずい。
0180デフォルトの名無しさん2008/08/03(日) 19:40:52
Windowsは、プログラム終了時に入出力チャンネルのクローズも
やってくれんでしょ？
0181デフォルトの名無しさん2008/08/03(日) 19:49:38
class hoge{
……
void write_all_data(void);
void clear_all_resources(void);
~hoge(void);
}

hoge::~hoge(void){
write_all_data();
clear_all_resources();
}

こういう形だとまずいってことじゃないの？
0182デフォルトの名無しさん2008/08/03(日) 19:50:40
>>175
まあ俺がそんなにファイルとか扱うプログラムを書かないだけだったりするけどな。

>>180
>>179が言っているように、デストラクタ内でログの書きだしとか、ロックファイルの削除とか、
そういった処理を行うとするなら
デストラクタの呼び出しを伴わない終わり方(exitとかSIGKILL)をすると
いろいろと面倒だよねって話。


うーん、exit派なんだけど、ちょっと心が揺らいできた。
throwしよっかな。
でもめんどくさいw
0183デフォルトの名無しさん2008/08/03(日) 20:19:12
>>182
悪いことは言わん、exit も throw もやめとけ。
どちらもあくまで緊急脱出手段だ。
0184デフォルトの名無しさん2008/08/03(日) 20:29:18
デストラクタの役割がメモリ解放だけだと思ってるうちは初心者
0185デフォルトの名無しさん2008/08/03(日) 20:43:10
>>184
他にどのような利用をするのですか？
0186デフォルトの名無しさん2008/08/03(日) 20:57:12
>>185
>>181
0187デフォルトの名無しさん2008/08/03(日) 21:08:54
>>180
入出力チャンネルって何？

ハンドルなら自動的にクローズされるけど
0188デフォルトの名無しさん2008/08/03(日) 21:17:28
exitなんて使ったら、名前付きパイプとかWindowsフックみたいな
プロセスを越えるリソースが開きっぱなしでリークするな。

他にもメモリキャッシュ実装しててflushされないとか、
キャッシュファイルが削除されないとか、
Excelみたいなファイル内に共有ロック情報書いてる場合にアンロックされないとか
リソースリーク／終了処理が正常に行われないケースは山ほどある。
0189デフォルトの名無しさん2008/08/03(日) 21:36:07
されねーよ。
どのプロセスがどのnamed pipeを開いているかぐらい余裕で把握している。
すべてのプロセスが解放したら消させる。

フックも把握していないといずれ面倒なことになる。

それにVistaからは、フック関数側のCallNextHookEx呼び出しに頼らず、
Windows側がひとつひとつ呼んでいるってのをどこかで呼んだ気がするが。
0190デフォルトの名無しさん2008/08/03(日) 21:37:41
exit使ったって正常に動くプログラムは書けるが

そんなプログラムを書く奴は人に信用されない
無学に見られるから止めておくほうがよろし
0191デフォルトの名無しさん2008/08/03(日) 21:39:43
>>188
言いたいことはよくわかるが
exit なんぞ平気で使う奴には通じない話だ
0192デフォルトの名無しさん2008/08/03(日) 21:47:35
190に補足すると
作成者が注意力を発揮すれば exit 使う正しいプログラムは書けるが
ちょっとした改造の度にそんなところに注意力を使わなければならない時点で
稚拙な設計だ

優秀なプログラムは、無駄なバグ混入リスクを取らないよう書かれている
で、ホントに必要なときに限りテクを使う
0193デフォルトの名無しさん2008/08/03(日) 21:55:56
ところで、デストラクタでリソース解放するのって優秀なの？
0194デフォルトの名無しさん2008/08/03(日) 21:58:06
エラー処理できないのでダメダメ
0195デフォルトの名無しさん2008/08/03(日) 21:59:40
>>193
他の方法ではまともに例外安全なコードが書けない
0196デフォルトの名無しさん2008/08/03(日) 22:00:26
auto_ptrやsmart_ptrをダメダメだと言い捨てるとは、勇者だな。

んじゃ教えてくれ。
リソースの解放でエラーが発生したら、一体どうすりゃええんだ。
0197デフォルトの名無しさん2008/08/03(日) 22:01:00
すみませんが、助けていただけないでしょうか。
ttp://www.geocities.jp/menopem/
こちらのDirectXウィンドウ化ツールで使用する補助DLLとして、
「窓化起動したアプリケーションを再びフルスクリーン化する」
というものを制作したいのですが、C++の経験が無いために苦しんでいます。
補助DLLの仕様についてはツール内にtxtで含まれているのですが・・・。

用途としてはどうしても色化けしてしまう古い(256色専用)ゲームをパレットエミュレートで正常に動かすことが目的なのですが、
窓化した場合、窓の描画領域の0.0をディスプレイの0.0に合わせないと、画面描画や文字描画がその分ずれてしまう現象に見舞われてしまったので、その簡易な修正のためです。
問題のゲームは下のデザートタイム夢幻の迷宮とファントムナイト夢幻の迷宮Ⅱです。
ttp://www.parsley.gr.jp/ps_top1.html (リンク先18禁)
0198デフォルトの名無しさん2008/08/03(日) 22:02:08
>197続き
一応書いてみたコード。ウィンドウハンドルとか判りませんorz
#include <windows.h>
#include <stdio.h>

BOOL APIENTRY DllMain( HANDLE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
{
static TCHAR  processName[MAX_PATH];

switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
GetModuleFileName(0, processName, MAX_PATH);
processName[MAX_PATH-1] = '\0';

OutputDebugString("補助DLLロード確認");
MessageBox(0, processName, "補助DLLロード確認",  MB_OK);

SetWindowLong(HANDLE, GWL_STYLE, WS_POPUP | WS_MINIMIZEBOX | WS_VISIBLE);
SetMenu(HANDLE, NULL);
SetWindowPos(HANDLE, HWND_TOP, 0,0,1400,1052, SWP_FRAMECHANGED | SWP_NOCOPYBITS);

break;

case DLL_PROCESS_DETACH:
OutputDebugString("補助DLLアンロード確認");
MessageBox(0, processName, "補助DLLアンロード確認",  MB_OK);
break;
}
return TRUE;
}
0199デフォルトの名無しさん2008/08/03(日) 22:02:26
DirectXスレに行って下さい
02001992008/08/03(日) 22:05:18
訂正、Win32APIスレへ
ClientToScreen、GetWindowRectなど
0201デフォルトの名無しさん2008/08/03(日) 22:08:04
>>194
例外安全でエラー処理出来る方法を、世界中で多くの人が求めています。
教えてあげて下さい。
0202デフォルトの名無しさん2008/08/03(日) 22:08:08
>>195
ぜひkwsk
0203デフォルトの名無しさん2008/08/03(日) 22:12:47
>>196
releaseとかcloseのような名前の解放用メンバ関数を用意しておいて、
エラー処理が必要ならそれを明示的に呼び、要らなければデストラクタに任せるとかいう話を聞いたことがある。
0204デフォルトの名無しさん2008/08/03(日) 22:15:44
>>202
//RAIIなコード
void fn1(){
　　　File fR;
　　　File fW;
　　　fR.open("read.txt");
　　　fW.open("write.txt");
　　　fn3(fR, fW);
}
//デストラクタに頼らずリソースを解放するコード
void fn2(){
　　　File fR;
　　　File fW;
　　　fR.open("read.txt");
　　　fW.open("write.txt");
　　　try{ fn3(fR, fW); }
　　　catch(...){
　　　　　　try{ if(fW.opend()){fW.close();} }
　　　　　　catch(...){
　　　　　　　　　if(fR.opend()){fR.close();}
　　　　　　　　　throw;
　　　　　　}
　　　　　　if(fR.opend()){fR.close();}
　　　　　　throw;
　　　}
　　　try{ if(fW.opend()){fW.close();} }
　　　catch(...){
　　　　　　if(fR.opend()){fR.close();}
　　　　　　throw;
　　　}
　　　if(fR.opend()){fR.close();}
}
0205デフォルトの名無しさん2008/08/03(日) 22:23:05
RAII様様
GCよりよっぽど使えるわ
0206デフォルトの名無しさん2008/08/03(日) 22:25:54
それは言いすぎな気がするけど、だからこそC++を使う気になるのは俺もそう。
0207デフォルトの名無しさん2008/08/03(日) 22:27:53
>>204
サンクス。
0208デフォルトの名無しさん2008/08/03(日) 22:28:31
RAIIのほうは解放に失敗したらハンドルリークするから駄目だね
0209デフォルトの名無しさん2008/08/03(日) 22:30:36
ついでにGCがあるjavaとC#も。
リソースのcloseに関してはjavaがもっともカス。

//java
void fn2(){
　　　InputStream ist = new FileInputStream("a");
　　　try{
　　　　　　OutputStream ost = new FileOutputStream("b");
　　　　　　try{
　　　　　　　　　fn3(ist, ost);
　　　　　　}
　　　　　　finally{ try{ ost.close(); }catch(Throwable t){} } //(*1)
　　　}
　　　finally{ try{ ist.close(); }catch(Throwable t){} }
}
//(*1) catchで止めないとより重要なfn3内の例外が消される

//C#
void fn2(){
　　　using(StreamReader r = new StreamReader("a"))
　　　using(StreamWriter w = new StreamWriter("b"))
　　　{
　　　　　　fn3(r, w);
　　　}
}
0210デフォルトの名無しさん2008/08/03(日) 22:31:32
>>208
＞ハンドルリークするから
しません。それただのバグ。
0211デフォルトの名無しさん2008/08/03(日) 22:32:30
>>208
解放処理が失敗してどうやって解放するの？
プロセスを終了してOSに任せるくらいしか俺には分からない。

もし、デストラクタが例外投げた場合の話であれば、そもそもそれが間違いだよな。
デストラクタは何があろうと例外を投げちゃまずいよ。
0212デフォルトの名無しさん2008/08/03(日) 22:38:12
Dはまだscoped_ptrなRAIIがあるからいいけど，それすらない
C#，Javaだとリソースの解放ﾏﾝﾄﾞｲよな
0213デフォルトの名無しさん2008/08/03(日) 22:42:45
>>210
> しません。それただのバグ。

失敗はするでしょ。
成功するまでループするの？
0214デフォルトの名無しさん2008/08/03(日) 22:44:50
>>213
しません、は「リークする」にかかってるんでしょ。
0215デフォルトの名無しさん2008/08/03(日) 22:49:18
解放失敗すればリークするだろ
0216デフォルトの名無しさん2008/08/03(日) 22:54:13
解放に失敗するリソースをどうやって解放するんだ
もはやリークは避けられない運命としか
0217デフォルトの名無しさん2008/08/03(日) 22:54:48
>>215
>>208の人は「RAIIのほうは」って言ってるんだし、
解放失敗すればリークってのはRAII関係無いだろ。
脈絡の無いレスは止めておいた方がいい。
0218デフォルトの名無しさん2008/08/03(日) 22:55:09
明日死ぬかもしれないだろ
0219デフォルトの名無しさん2008/08/03(日) 22:55:49
>>215
では、RAIIを使用せずに開放メンバ関数を手動で呼べばリークしないんですね
0220デフォルトの名無しさん2008/08/03(日) 22:56:36
>>218
唐突過ぎて不覚にもﾜﾛﾀ
0221デフォルトの名無しさん2008/08/03(日) 23:00:43
まあ以下>>208はスルーで
アホは放置
0222デフォルトの名無しさん2008/08/03(日) 23:08:24
>>211
>>204って解放に失敗したらデストラクタから例外投げるよって意味じゃないの？
そうでなければ、

    try{ fn3(fR, fW); } catch(...) { }
    try{ if ( fW.opend() ) { fW.close(); } } catch (...) { }
    try{ if ( fR.opend() ) { fR.close(); } } catch (...) { }

とかいう暴挙に出てもいいのかな。
0223デフォルトの名無しさん2008/08/03(日) 23:16:18
>>222
fn3の例外は潰したら駄目。
他はまぁアリかな。
0224デフォルトの名無しさん2008/08/03(日) 23:31:12
>>166の"ギリギリ"ってプログラムに拠るって意味かね？
それとも、クライアントプログラムでもサーバープログラムでも、
１年かかって計算するようなプログラムでも、"本当に不可避な場合"だけを指してるのかな？

おれは前２者しかやったことないから、それ以外がよく分からないんだけど、
クライアント側ならOKと判断してたし、サーバー側も月一回程度の再起動はゆるされたんで、
"ギリギリ"がよく分からない。　よかったら教えて欲しい。
0225デフォルトの名無しさん2008/08/04(月) 00:02:57
>>183
throwもやめとけって、じゃあどうするの？
0226デフォルトの名無しさん2008/08/04(月) 00:09:32
>>225
異常系はかまわんけど、正常系で throw で抜けるはよせ。
return で main() まで帰れ。
0227デフォルトの名無しさん2008/08/04(月) 00:12:08
>>226
異常系って言うと、メモリが足りないとか、電力が足りないとか？
0228デフォルトの名無しさん2008/08/04(月) 00:19:12
頭が足りないとか。
0229デフォルトの名無しさん2008/08/04(月) 00:24:14
>>227
throw の使い方は派閥があるみたいだけど、俺は寛容派なんでファイル
オープンに失敗した程度のエラーや、ユーザーがキャンセル操作を行った
程度のことでも throw を使っていいと思う。
0230デフォルトの名無しさん2008/08/04(月) 00:49:30
テンプレートクラス内テンプレートクラスの演算子オーバーロードをしたいのですが、
どのように記述すればよいでしょうか？

例えば、
template< int m > struct foo{
 template< int n > struct bar{};
};
に対して、operator*( int, foo<m>::bar<n> )を定義したいのですが、
fooのクラス内静的関数として定義すると怒られますし、
グローバルな領域で
template< int m, int n > foobar operator*( int, foo<m>::bar<n> )
とやってもやはりコンパイルが通りません。
0231デフォルトの名無しさん2008/08/04(月) 00:53:32
>>229
プロジェクト内で一貫した方針で使ってる分にはいいんじゃないかと思う。
02322242008/08/04(月) 01:07:07
無視されてるのか勘違いされてるのか、よくわからないけど、
とりあえずあいまいな質問だったし、>>229が答えのような気がするので、
お礼いってたいさんします。　さんくす。
0233デフォルトの名無しさん2008/08/04(月) 01:09:08
煽ってたわけじゃなくて、本気で聞いてたのか……
02342322008/08/04(月) 01:38:27
>>233
すいません、本気でした。。
02352302008/08/04(月) 02:24:03
template< int m, int n > foobar operator*( int, typename foo<m>::template bar<n> )
でとりあえず自己解決したような気がします、すいません。

それにしてもこんなところにtemplateをつける用法があるんですね。
0236デフォルトの名無しさん2008/08/04(月) 09:52:02
RAIIだとハンドルリークする
について、まともな反論は結局なかったな

なんであんな誤った手法がまかり通ってるんだろうな
0237デフォルトの名無しさん2008/08/04(月) 10:08:39
>>236
RAIIだとハンドルリークする
について、まともな主張は結局なかったな
0238デフォルトの名無しさん2008/08/04(月) 10:13:27
>>236
俺の誤解でなければ、>>208と同じ人or意見ということだよな？

そもそも>>208自体が説明出来ていないので、
反論以前に、まともな主張になっていないわけだけど。

釣りかな？
0239デフォルトの名無しさん2008/08/04(月) 14:45:58
CloseHandleが失敗したらハンドルリークするんですが、どうすればいいんですか＞＜
0240デフォルトの名無しさん2008/08/04(月) 14:55:24
>>239
何事も完璧を求めると大変です。
どうやっても閉じれないハンドルなど捨ておきなさい。
0241デフォルトの名無しさん2008/08/04(月) 14:59:40
close失敗したハンドルって普通リークしたって言わないよね
0242デフォルトの名無しさん2008/08/04(月) 15:08:34
CloseHandleが失敗する原因を突き止めてください。
0243デフォルトの名無しさん2008/08/04(月) 15:41:16
普通はログ吐くよね
吐けな(ry
0244デフォルトの名無しさん2008/08/04(月) 19:16:59
グローバル変数やグローバル関数に一律で大域識別子：：を付けるというのは
C++では当たり前ですか？確かに名前の衝突は起きにくくなりますが
いちいち付けるのもなぁとも。やっぱり大規模なプログラムなんかだと
そうやっといたほうが良いのですかねぇ。
0245デフォルトの名無しさん2008/08/04(月) 19:25:44
必要なら付けろ。
不要なら付けるな。
よほど変なルールじゃなければ従え。
0246デフォルトの名無しさん2008/08/04(月) 21:10:12
RAII使っても使わなくてもCloseHandleに失敗したときの対応はニタリヨッタリじゃない？
RAIIの欠点としては弱いのでわ？RAII使うメリットを考えるとRAIIダメとは思わないなあ。
0247デフォルトの名無しさん2008/08/04(月) 21:21:43
何を言ってるんだ。
0248デフォルトの名無しさん2008/08/04(月) 21:23:45
>>239
情報隠蔽の基本からやり直せ
0249デフォルトの名無しさん2008/08/04(月) 22:26:03
RAIIってリソース破棄の順序も制御できるのかな。
ファイル書き出し → アンマウント みたいに。
0250デフォルトの名無しさん2008/08/04(月) 22:38:46
>>249
RAII≒デストラクタ
後はもう自明だろう
0251デフォルトの名無しさん2008/08/05(火) 08:58:00
>>249
アンマウントに失敗したらリークどころじゃなくなるからRAII方式はやめとけ
0252デフォルトの名無しさん2008/08/05(火) 09:57:46
キチガイが沸いているようですね
■ このスレッドは過去ログ倉庫に格納されています