を区別(しない|できない)人がいる模様。職場に。
まぁ実害はないが、もりもり出てくる Warning の山に
気づかないのだろうか。

char* p = buf; .... ; *p = NULL; とか。
memset( buf, NULL, sizeof( buf ) ); とか。

あと const。
char* p = "ABCDE"; とか。

さらにはファイルの最後が空行でなく、最後の行がいきなりEOFに 突入してるとか。
C言語的には動作未定義だったと思うけど、ともかく Warning が出る。

今日発見したすげぇコード in 仕事。
ファイルにロックをかけてから何かを書き込みたいらしい。

Windows版ではまず fopen() でファイルを開く。
そして返ってきた FILE* を HANDLE にキャストして LockFile()に渡す。
そして fwrite() で書き込む。
凄い。凄すぎる。...っておぃ。
まぁ一瞬 _beginthread() の返り値を WaitFor 系関数で待つ
みたいなやつかと思ったけど。

UNIX版ではまず fopen() でファイルを開く。（ここまで同じ）
それから同じファイルを open() でも開く。...??
open() で開いたファイルディスクリプターに fcntl() でロック
をかけてからおもむろに fwrite() で FILE* を使って書き込む。
...なぜじゃぁ。
しかもご丁寧に write() で FD に直接書き込むコードが コメントアウトしてある。

Visual C++ での話。

if( i > 100 ){
__asm int 3
}

（BLOCKQUOTE の中でのインデントの付けかたがわからん。）
みたいにすると、iが100より大きいときだけブレークする。
Release時には全部消しておくこと。
# 日記っちゅうより、メモだな。

って面倒だなと思うのは、いちいちthrows宣言しないといけない。
たとえば関数AがBを呼び、BがCを呼び出す場合に、
Cで例外が発生してそれをAで受け止めるとする。
でもって、Cで処理が変わって新たな例外が発生するように
なったらAとCの処理が変わるのは仕方ないとして、
途中のBでも "throws" の宣言を追加しないといけない。
しかも例外の名前って妙に長かったり...
ま、１個ぐらいだったらいいけど、すげぇ深かったりした日には、 あぁた。
まぁ、C++的には深い場所の例外を catch するっつちゅうのは
ある程度の覚悟が必要なことだから途中ももちろんチェック
しないといけないのは気持ちはわかるけど、
Javaなんだし、別にいいやん。
ま、本来はそういう変更が発生しないようにクラス設計を...
っちゅうことになるんだろうけど...。

MSの（もちろん SQL Server/MSDE 用）JDBCは再配布に制限があると。
というわけで、JDBC-ODBCブリッジ（Type 1 JDBC）を 使うことに作戦変更。
それでもODBCの再配布が必要なことに変わりはないが、
ODBCはいずれにせよ必要なのだからいいのだ。
そしたらまたもやJDBCの非互換性が。

SELECT A, B FROM ...

で取り出した結果は A、B の順番で取り出さねばならず、
決して B、A の順番には取り出せないみたい。
JDBCの非互換性というよりはODBCがらみの制限もしくは
ブリッジの仕様なのかもしれないが。
結構悩んだ。

おまけ
Longhorn では描画回りも含めて API が一新されるらしい。
前に書いた解像度 16 ビットはそれで解消するんだろう。

からいつのまにか復活しなくなっていることが発覚。
前は何事もなく復活してたのに。
ドライバ入れ替えたり、Windows Update とかしたから
そのうちどれかがいけなかったのだろう。
ハードは全然いじってないし。
# その割にトピックがハードウェアー
たまに使っていたのに。（＝たまにしか使わなかったのだが）
休止状態も同じく復活しない。
こっちはこのマシンでは初めてやったので
前からなのかどうかは不明。
たまに便利だったのになぁ。＜ 未練

はどっちも最大32kみたい。

Xは各所でx座標やy座標が符号つき２バイトだし、
Windowsもマウスクリックのイベントとかのマウスカーソルの
座標はx、yそれぞれ２バイト。
(LPARAMの上位ワードと下位ワードに入っている)

ふむ、そうすると画面の解像度が32kを超えるといろいろ
まずいことになりそうな予感。
ま、しかしここ約10年で一般的な画面解像度は２倍ぐらいにしか
なってなくて、32kまではまだまだ10倍以上だから余裕か。
でも、 こういう人もいるからあと数倍しか余裕がないともいえる。
将来ある時点からトチ狂ったように高解像度化が進まんとも限らんし。

ふと思い立って会社でいつも使ってる Win2000 にデフラグを かけてみた。
システムインストールしてから１年半ぐらい、一度もやったこと なかった。
そしたら解析結果は真っ赤。（つまり断片化しまくり）
デフラグしたら起動とシャットダウンがかなり早くなった。
やってみるもんだ。
なんか忘れていた基本を思い出した感じ。
しかし、たまにマウスカーソルが固まる症状は治らない。
まぁ特に期待はしてなかったけど。

しかし最近は CD-RW も24倍速ですか。すげぇ。
CD-Rとかあんまり使わなくて、R 6倍、RW 4倍のドライブしか
持ってなかったので全然気付かなかった。

CD-Rにバックアップしたときにシングルセッションで書き込んだみたいで
次のときに追記できなかったので AC ＜ できねぇって

状況:ON/OFFが６個のデータ（６ビット）のやり取りの フォーマットを決めないといけない。
ただし、もろもろの都合上、テキスト。

GK 「ほにゃららのフォーマット決まりましたかぁ」
同僚 「４バイト整数で下からのビット６個でONとOFF」
GKほか１名 「テキスト形式っちゅっとるやろ。テキストにどうやって変換すんだよ。」
同僚 「sprintfで%d」

仕事でJDBC。ターゲットはとりあえずSQL Server/MSDE だけど
PostgreSQL、Oracleにも対応すべし。

SQLの非互換性をなめていたかも。
まぁ、データ型とかが違うのはともかく、 SELECTでの問い合わせぐらいなら一緒かな
などと思っていたら、むむぅ。
連続でID作ってくれるやつの扱いとか。(IDENTITY/SEQUENCE)
まぁSQLの非互換性はある程度覚悟していたが、 JDBCの非互換性もありえると。
あるRDBMS用のJDBCだと実装されてない関数とかあったり。
ResultSet#getInt()がMS用のは同一レコードの同一カラムに ついては
１回しか呼び出せなかったり。＜別に何度も呼べてもいいのに。
（PostgreSQLでは複数回呼び出し可能。）
できればJava部分はRDBMSに依存せずに共通にしたいのだが...