09/08/06 14:21:59
Windows が要求されたリソースを見つけられないか、割り当てられないときに発生
925:デフォルトの名無しさん
09/08/06 15:05:12
解決するにはその例外で止まった時点で、その場所を見るとか呼び出し履歴を見るなりなんなりして
直接の原因を調べることだろうな
926:デフォルトの名無しさん
09/08/06 22:24:26
24文字のテキストを百万回連結して最後にテキストボックスに表示する操作をやろうとしているのですが、
どうやったら一番早いでしょうか？
毎回CStringで連結してたらあまりに遅かったので、
char配列のバッファAに16kBまで書き込んで、次にCStringのバッファBで16回連結し、
それを16回分たまるごとにCStringのバッファCで連結して最後にテキストボックスに出すようにしたら
少しは早くなりましたが…
927:デフォルトの名無しさん
09/08/06 23:41:35
なんでバッファ分けるんだ
小分けにする理由はあるの？
928:デフォルトの名無しさん
09/08/06 23:58:14
はなくそとMFCは同じくらいうまい。
929:926
09/08/07 00:43:38
>>927
やはり大きい領域で連結操作すると重いみたい。
CString一段から二段に増やしたら時間短縮した。
それ以上増やしてもあんまり変わらなかったけど。
930:デフォルトの名無しさん
09/08/07 00:50:06
10000文字あったとして連結して10001文字にしたら多分
10001文字の領域を確保して10000文字の領域からコピーして
10000文字の領域を破棄してるから遅くなると考えてなるべく小分けするって
手法をとったんだろ？
javaでも似たような動作したな
毎回こういう文字列オナニークラスみるたびに思うけど
汎用設計下手糞すぎる奴がなんでこんなもの手をだすんだろね
931:デフォルトの名無しさん
09/08/07 06:50:06
>>929
なんかズレてるな
＞char配列のバッファAに16kBまで書き込んで
これを24MBのchar配列にして
CStringの連結を一回も行わずに
テキストボックスに渡すのは駄目なのか？
932:デフォルトの名無しさん
09/08/07 17:22:25
CStringも中の人はchar配列だし、
最初から大きめに領域取っておけば、
不足するたびに何度も領域増やすような頭の悪い状況は避けられる。
933:デフォルトの名無しさん
09/08/07 17:34:39
連結してテキストボックスに出力する程度のことでわざわざ CString 使わなくても
char 配列で十分だろーに。
使いたいなら CFixedStringT というのもある。
934:デフォルトの名無しさん
09/08/07 18:09:03
タスクバーに表示されない常駐プログラムを作成しています。
いろいろとサイトを拝見してたところ簡単な方法で、
OnSysCommand()内で、最小化時に
ShowWindow(SW_HIDE)で本体を隠し、CDialog::OnSysCommand()が呼ばれる前に
終了する方法を見つけましたが、この方法で特に動作的に問題は無いでしょうか？
サンプルを作成してみたところ、正常に動作しているように見えます。
void CTest::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == IDM_ABOUTBOX)
{
CAboutDlg dlgAbout;
dlgAbout.DoModal();
}
else
{
switch(nID){
case SC_MINIMIZE:
//ここで終了
ShowWindow(SW_HIDE);
return;
}
CDialog::OnSysCommand(nID, lParam);
}
}
935:デフォルトの名無しさん
09/08/07 18:21:40
>>934
CDialog::OnSysCommand() が何をしているのか調べるとわかる。
936:デフォルトの名無しさん
09/08/07 19:02:30
>>935
アプリ主なシステムコマンド(最小化、最大化、クローズなど)のデフォルト処理を行っているんですよね。
それを飛ばして、勝手にウインドを隠すこと自体、問題ないのか少し不安になり質問しました。
クローズボタンの無効化などで、OnSysCommand()を呼ばずに終了する方法は見たことはあるのですか・・・・
937:デフォルトの名無しさん
09/08/07 19:18:29
>>936
難しく考えなくていい。
CDialog::OnSysCommand() は メッセージを DefWindowProc() に渡しているに過ぎない。
DefWindowProc() は処理されないメッセージを処理する関数。
原則として、処理をしたメッセージをこの関数に渡す必要はない。
938:934,936
09/08/08 09:39:20
>>937
ありがとうございます。参考になりました。
メッセージ処理を行っているだけで、特に必要なければ、
飛ばしてもよいのですね。
939:926
09/08/09 01:36:51
>>931-933
いや、十分な大きさの配列宣言したら実行時エラーが出てしまって…
（その後、malloc系の関数で別途メモリを確保したら一応できましたが）
240万文字を保持するにはCStringとかにするしかないのかなと思ってしまっていました。
それに、毎回240万文字出さなくちゃいけないわけではなくて、
そのプログラムをある特定の目的で使ったときのみその必要があるだけで、
通常は24文字が数十からせいぜい数百くらいしか生成されないんです。
そして正確な必要量は、確率で決まるので実行するまで不明という仕様。
で、926の書き込みの後さらに試行錯誤した結果、文字列の生成・連結の実行時間は既にかなり短縮できていて、
現状では実行時間のほとんどがCEditのSetWindowTextに費やされていたことがわかりました。
ちょっと私の実力ではCEditに代わるものをなんとかするとか無理なので、あきらめることにします。
お騒がせしました。
940:デフォルトの名無しさん
09/08/09 14:10:34
>十分な大きさの配列宣言したら実行時エラーが出てしまって
>そして正確な必要量は、確率で決まるので実行するまで不明
char* lpString = new char[必要量];
// to do ...
delete [] lpString;
941:デフォルトの名無しさん
09/08/09 16:00:27
>そして正確な必要量は、確率で決まるので実行するまで不明
これはおかしい
上限は仕様で決めなければならない
だってランダムで明らかにＰＣのスペックを上回る量だったらどーすんだよ
ＨＤＤに一時的に保存しておく必要だってでてくるし
本当は上限はあるにはあるんだけど概算を出すのが面倒だからやってないだけだろ
嘘をつくな
嘘をつくと後で大変なことになるぞ
自分にとってもよくない
942:デフォルトの名無しさん
09/08/09 16:04:29
・・・お前、そこだけ読んでるだろ。
943:デフォルトの名無しさん
09/08/09 16:14:56
>>942
内容変わらないじゃん
944:デフォルトの名無しさん
09/08/09 18:57:31
>>939
そもそも数メガのテキストを渡すとか
まともなパフォーマンスにならなかった気がする
テキスト渡すだけでフリーズしかけ、
スクロールする度にフリーズしかけ・・・