No Such Blog or Diary

1つのビットマップオブジェクトを同時に複数のデバイスコンテキストで選択することはできない．なので，複数のビットマップをサイクリックに BitBlt したいときに，毎回新しい（コンパチの）デバイスコンテキスト作ってから解放せずにほっとくと，次回からそのビットマップが描画できなくなる．このようなバグを埋め込んでしまった場合にそれを解決しようとする試みは人それぞれだと思うところだが，毎回新しくビットマップをロードしてハンドル作りまくるのはどうかと…　これをやるとリソースか関係でむちゃくちゃになるのでとりあえず作ったものは解放しましょうと言いたい．

とは言え今後自分がはまらないとも限らんので記録として書いておくことにしよう．

ということで数日前の現象( non-blocking の send ではまる)を再現させようと思ったらプログラムはすでに書き換わってて再現不能．別のプログラム書いて試してみたら今度はうまく送信したバイト数だけが戻っていたので実は数日前の現象は見間違いだったか別の問題との兼ね合いだったように思える．ただ，どっかであの記述を見た記憶があるのでほんとのところどうなんだろうか？　それはさておき，今度は "MSG_DONTWAIT" 指定してるのにブロックされてしまう現象が…

適当なバージョンの libstdc++ がほしいので gcc2.95.2 をコンパイル(ムダ)．しかし， glibc-2.2 以降ではパッチを当てないとコンパイルできないことに気づかず時間を無駄に．

結局　ftp://ftp.ilog.fr/pub/Users/haible/utf8/gcc-glibc-2.2-compat.diff のパッチを当てなさいとのこと．それはさておき glibc のバージョンを下げないとやりたいことができないのかも…

５年前のLinux用バイナリ配布って…　うまく動きません．

socket でデータを送るときに send に MSG_DONTWAIT を指定して非ブロックにして送る．

int ret = ::send(sock, buf, len, MSG_DONTWAIT);

このとき，戻り値 ret は -1 ならエラー, 0 ならすべて送信キューに入った，正の値なら送信キューに入れられただけの長さ．とういことで，戻り値は送った長さではない．write と違うんじゃないのかとマニュアルに問いかけたい…

追記：

後日再び試すがちゃんと write と同じ結果になっている( send を再び)．すべてキューに入った場合にもう一度0バイトを送信しにいってたのかもしれないなぁと思ってみたり．

５問の計算時間を全部足しても１分未満．もちろんプロセッサひとつで…　こんなんでいいのだろうか？　サンプルプログラムに少々手を加えただけでこの結果なので全チーム予選通過という事態が待っている気がする．