鏑矢の憂鬱２００１年２月後半

#include <iostream.h>
#include <fstream.h>
#include <stdlib.h>
typedef struct Test{
  int dat1, dat2;
  double a[2];
};

int main(){
  Test a;
  ofstream out_file("test.dat");
  a.dat1 = 10;
  a.dat2 = 11;
  a.a[0] = 1.5;
  a.a[1] = 3.7;
  out_file.write((char*)&a,2*sizeof(a.a[0]) + 
    sizeof(a.dat1) + sizeof(a.dat2));
  ifstream in_file("test.dat");
  in_file.read((char*)&a, 2*sizeof(a.a[0]) + 
    sizeof(a.dat1) + sizeof(a.dat2));
  cout << a.dat1 << ' ' << a.dat2 
    << ' ' << a.a[0] << ' ' << a.a[1];
  return 0;
}

　
　これなんですけれども、データの並びが変わることなくうまく動いてくれていますが、 write()した時に、データの並び順の保証はあるんでしょうか？　あったらいいなぁ

・えーっと、データの並び順ってことそのものは大丈夫。 Test 構造体型の変数として a を作ったでしょ、その変数 a のメモリ上のバイナリーデータそのものがファイルに書き込まれるんで、同じく read() でそのまんま取り込めば問題なし。
　
・だけど、それ以外はちょっと問題（汗）。まず構造体のサイズ。構造体の中の変数はそのまんま置かれるんじゃなくて、変数の間に無駄な空間が作られる場合があるんです。この仕組みをアライメントって言います。たとえば VC の場合、 Test::dat1 と Test::dat2 の型を char にすると動かなくなっちゃいます。 dat1 と dat2 の間に無駄な領域が作られちゃうんで、この例だと変数 a の最後が書き込まれないです。
　
・このあたりはコンパイラの設定によるし、今回みたいにちょうどアライメントとサイズが同じだったりするとうまくいくんだけど……。そういうの回避するためにも、 sizeof( Test ) の値を write() に渡しましょう。っつーか、ホント言うと構造体を write() するのは避けた方がいいんだけどね。コンパイラ依存ってことは、移植したら前のデータが使えないなんてことに……。面倒だけどデータひとつひとつ書き込むのを勧めますです。
　
・あと、わてが試したときは ofstream::close() を呼ばないと ifstream でファイルを開けなかったです。だから ifstream::read() は失敗してたんで変数 a の値がそのまんま残ってました。「うまくいってた」のがもしかしたらその理由って可能性も。その辺かなぁ。古いコンパイラみたいだからデバッグ大変だと思うんで、少しずつテストしていった方がいいかもしんない。今回のは読み込みと書き込みを別プログラムにするとか。
　
・もひとつお便り。

　こんにちわ。マルチスレッドのワーカースレッドのことなんですけど、このワーカースレッドが走ってる時にアプリケーションを終了するとどうなるんでしょうか？
　
　ワーカースレッドの終了を待って終了できてればいいんですけど...もし、できてなかったら終了を待つにはどうすればいいんでしょうか？

・ん～、スレッドがどういうことしてるかに寄る、ってことみたいです。 MSDN の "Terminating a Process" ってページを見ると "When a process is terminated, all threads of the process are terminated immediately with no chance to run additional code." って書いてあるんで、その場ですぐスレッドが中止されるみたいです。
　
・ってことは、後処理が必要な場合にはまずいかも。まー、たいがいのことはプロセスが削除されればなんとかなってるんで、大丈夫だとは思うけど。ウィンドウズのハンドル系はたいがい大丈夫。でも、たとえばネットワークに接続してて、いきなりこっちが閉じるとまずい場合とかは問題かも。その辺は、マルチスレッド関係なく「デバッグの中止」とかするとそういう状態になるんでその辺でチェックするといいかも。
　
・で、スレッドを待つには WaitForSingleObject() って API を使います。これにスレッドのハンドルを渡すと、もしスレッドが終了してたらすぐ返ってきて、終了してなかったら終了するまで返ってこないとゆー機能を持ってます。とりあえずこんな感じに。
　

void Func( LPVOID )
{
//  Sleep( 3000 );
    TRACE0( "Func infinited\n" );
}

void Test()
{
    DWORD dwThreadID;
    HANDLE hThread
        = CreateThread
            ( 0, 0
            , (LPTHREAD_START_ROUTINE)Func
            , 0, 0, &dwThreadID );

    Sleep( 3000 );
    TRACE0( "Sleeped\n" );
    WaitForSingleObject
        ( hThread
        , INFINITE );
    TRACE0( "Thread infinited\n" );
}

　
・こうすれば、スレッドの方が先に終わってるんで WaitForSingleObject() はすぐに返ってきます。逆に、 Test() 内の Sleep() をコメントアウトして Func() の Sleep() を機能するようにすると、 WaitForSingleObject() がちゃんと待ってくれるのが分かると思います。この処理をアプリの最後にすれば大丈夫。たーだ、もしスレッドが「終わらないかも」とか「すんごく時間がかかるかも」って場合にはユーザーに迷惑がかかるんで、他の方法の方がいいかもしんない。
　
・もひとつお便り！

　三好です。
　
　エディタ作りの最後の詰めでこけています。CFindReplaceDialog の使い方を教えてください。とくに、検索すべき文字列をダイアログから取得する方法が知りたいです。なぜかうまくいきません。
　
　よろしくお願いします。

・おおっ、ついにそこまで行きましたか！！　しかし CFindReplaceDialog ってものがあるとは知らなかった（汗）。このパターン最近多いな……。えっと、とりあえず簡単にテストしてみました。なんかエラー出ちゃうけど、とりあえず検索ダイアログの文字列は取得できてるんで。
　

CFindReplaceDialog g_cFindDlg;

void Test()
{
    if( g_cFindDlg.GetSafeHwnd() == NULL )
    {
        g_cFindDlg.Create( TRUE, "" );
    }
    else
    {
        // これはテスト用。
        TRACE( "%s\n", g_cFindDlg.GetFindString() );
    }
}

LRESULT WindowProc(UINT message
    , WPARAM wParam, LPARAM lParam) 
{
    if( message == RegisterWindowMessage( FINDMSGSTRING ) )
    {
        LPFINDREPLACE lpfn
             = (LPFINDREPLACE)lParam; 
        TRACE( "%s\n", lpfn->lpstrFindWhat );
    }
 
    return 0;
}

　
・検索ダイアログの「検索」ボタンを押すと、 FINDMSGSTRING で登録されたメッセージが送られてくるんで、それをウィンドウプロシージャで受け取って、 lParam を LPFINDREPLACE にキャストしたのの lpstrFindWhat に検索文字列が入ってるんでそれを元に検索すればいいようです。
　
・もひとつの「テスト用」の方でも取得できるんだけど、検索ダイアログの「検索」を押さないと lpstrFindWhat の中身が更新されないんで、最後に押したときの文字列しか取得できないです。っつーか FINDMSGSTRING の lParam と g_cFindDlg.m_fr は同じものだし。なんかこういう「既製品」はどうも信用できないとこが（汗）。
　
・でわまたっ！

　
2001/02/26 (Mon)

・今日はお便り紹介～。

　三好です。
　
　やはりエラーが出ますか。「うまくいかない」と私が書いたのは、アサートかけられてしまうことでした。やはり自前で実装するほうがいいような気がしてきました。
　
　現在バグ取りとコードの単純化を図っているところです。これで、検索機能とかつけたら、立派にエディタ完成ですね。

・昨日のうまくいかないって ASSERT() のことでしたか。 _free_dbg() で発生してたんでコールスタックでどの delete で発生するのか調べてみたら CFindReplaceDialog::PostNcDestroy() で delete this してました（汗）。どういう理由でこういう仕様になってるんだろう。フレームワーク関係のクラスならこういうのも分かるんだけど。
　
・とりあえず CFindReplaceDialog 型変数を new で作ってみてください。そうすれば delete が成功するんで。これでうまくいくはず。でもちょっと応急処置かも。んでも MFC の仕組み調べるのも面倒だしなー。
　
・もひとつお便り。

　ワーカースレッドについて質問したものです。
　どうもありがとうございました！めちゃくちゃ役にたちました。
　ネットワークをちょっと見に行くだけの機能なんでちょっとしか時間は食わないんですけど、終了処理がどうなってしまうのかと思ったもので...

・この辺って分かりにくくて難しいですもんね。基本は MSDN の Platform SDK を読み潰すってことになるんだろうけど、必ずしも分かりやすく書いてないし（汗）。それに英語だし（爆）。ウィンドウズプログラミングの壁のひとつかもしんないです。そういうの、分かりやすく簡単に全体的に書いてる本とかないもんかな……。
　
・でわまたっ！

　Microsoft(R) Visual Studio(R) 6.0 Service Pack 5の無償提供開始のニュースを受けて、さっそくダウンロードしてみました。
http://www.microsoft.com/japan/developer/vstudio/download/sp/
　
　インストールしてみると MFC42.DLL の更新日時が 99/10/27 です。
　
　手持ちの DLL をみると 99/04/27 なので(ファイルバージョン: 6.00.8447.0 -> 6.00.8665.0 製品バージョン: 6.0.300 -> 6.0.400 )新しくなっているような気がします。
　でも readme.htm を読むと、「6.3.10 Microsoft Foundation Classes (MFC) の問題」に「Service Pack 5 で修正された問題」の項目がありません。いったいどんな変更があったのでしょうか。それとも勘違いなのでしょうか。

・たぶん色々やったんだけど「問題」が「修正」されなかったんでしょう（爆）。もしくは「問題」が「追加」されたか（爆）。 VS のサービスパックってことは MFC のソースコードも着いてると思うから、バックアップ取っといて差分取ってみればどの辺が変わったのか分かったのかもしんない。 .Net まわりとかこそこそっと追加されてたりしそうだなー。うちはダウンロードはきついんで、Ｃマガに付いてきたら試してみるです。
　
・でわまたっ！