トップ «前の日記(2004-02-22) 最新次の日記(2004-02-24)» 編集

日々の破片

2004-02-23

_ もぐら

早速、子供と鑑賞。ライオンやシマウマなんかと違って、テレビや動物園とかで見られるわけではなく(って言うか、動物園で見たことは無いけど。テレビではあるかも知れないけど記憶には残ってない)、その意味でも未知との遭遇でおもしろかったです。というか、あそこをモグラが掘っているという現場（なぜか石が順番に揺れていくとか）や、掘られた跡、は見たことがあったけど現物が地上に出て活動しているところは始めて見ました。

確かにかわいいですね。特に3本目の尻尾を残して穴を開けて潜っていくところ最高。潜るスピードにびっくり、だけど、なかなか尻が隠れないとことか。あれって、芝生のところでは潜れなくて、花壇のところまで行って始めて潜れたということなんでしょうか?

かわいい害獣ってのは厄介だなぁ、とつくづく思うものの、こればっかりはどうにもならないですね。

_ char* p = new char(int);

ここがまずいというのはわかったものの、ちゃんとコンパイルが通る（正しいコンストラクタ呼び出しで、ポインタが返る）のにはあらためてちょっと衝撃(というのは大げさだけど盲点でした)。

多分このテの記述ミスはしたことはないとは思うが、危ないなぁ。

#include 
#include 
int main(int argc, char* argv[])
{
    if (argc > 1)
    {
	char* p = new char(strlen(argv[1]) + 1);
	strcpy(p, argv[1]);
	puts(p);
	delete[] p;
    }
    return 0;
}

をコンパイルして試す。

C:\Home\arton\test>cl ctest.cpp
cl ctest.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
 ...
C:\Home\arton\test>ctest aaaa  // この程度なら一見問題なし
aaaa
#でもこの例だと400文字くらい突っ込んだところでヒープのページ境界を越えて死ぬ。

_ 記号流

あれって、名前重複の回避が理由なんでしょうか? だったら、パッケージだけ管理すれば良いと思うんですよね。

むしろ台帳に変数一覧、プロシージャ一覧とかがあって、細かに動作を定義しているのかなぁ、とか想像しているんですが。なんていうか、工業製品の部品台帳みたく、A-01というネジは、AX-01というネジ穴で、発注先はAF-01、という感じ。と言っても工業製品がそういう管理をしているかどうかも想像なんですが。

で、安上がりな難読化手法（台帳がないとソースを読むのは外部の人間には無理）なのかな、とか。

少なくても1度とは言え(しかもCOBOLとは言え)見かけたことはあるから、なんかそんな変なことをやる理由/推奨している手法があるはずなんだけど(少なくても本屋のプログラミング言語コーナーでそんなのを奨めているのは見たことがないので、管理手法側なんだと思う)、まったくメリットがわからないので。

#もしネームスペースが単一でかつ1つの実行モジュールにリンクされることになる巨大なプログラムを複数人で開発し、しかも名前が8文字、かつローカルスコープの変数が取れない、といった条件があれば、まあ、わからないでも無いし、古いCOBOLだったら比較的その状態に近いかな(でも名前8文字ということは無いとは思う)、とは考えられるんですが。

#でもその場合は言語を変えるのが筋だと思います。少なくてもCならファイルスコープとローカルスコープがあるわけだし。

_ 素晴らしくないよう

困っている人が本当にいるらしいってのはわかるけど、

・長期的な視点：とりあえず、PoEAAでも読む

・中期的な視点：VB方式（後述）

・短期的な視点：全部、static。シングルスレッド。バッチ式（ANT駆動とか）

――殴られそうだけど、意外とまじめな提言。

かなぁ。

VBってクソみたいに言われるし、事実、ほとんどそうなんだけど、「ほとんど」ってのは違う面もあるわけで、大体、ダメダメな場合は

・Windowsのメッセージングを理解していない

・コンポーネント側がOLEオートメーションの仕様を理解していない（VBは被害者）

・byVal, byRefの区別がわかっていない(入門書でも見かけるが、ByRefを推奨し過ぎ。VBで書いている時点で速度をそんな細かいところに求めてはだめでしょう)

・コーディングスタイルがタコ

・プログラマが例外処理を理解していない（on error resume nextは禁止したほうが良いだろうな)

と言った点で、ちゃんとしたコンポーネントに対してトランザクションスクリプトパターンを適用して記述する分には、そんなにダメ言語じゃなくて、むしろ長所も多いとも言えるわけで、Javaで開発する場合も同じように、トップのメンバー→ユーティリティクラスやDAO（ビジネスメソッドまで持つかどうかは人数と時間に依存）、サービスレイヤーを作らせる、その他→トランザクションスクリプトパターンで1つのメソッド内で上のクラスを操作させる、とやっていけば、業務システムであれば、仮に落ちる一方のウオーターフォールでやっても大きく破綻することは無いと思います。と思うんだけど。だめかなぁ

_ ファイルのダウンロード

HTTPで日本語のファイル名を使いたい場合、Content-Dispositionにファイル名のエンコーディングを指定できない。

Current [RFC 1521] grammar restricts parameter values (and hence

Content-Disposition filenames) to US-ASCII. We recognize the great

desirability of allowing arbitrary character sets in filenames, but

it is beyond the scope of this document to define the necessary

mechanisms. We expect that the basic [RFC 1521] `value'

specification will someday be amended to allow use of non-US-ASCII

characters, at which time the same mechanism should be used in the

Content-Disposition filename parameter

少なくてもIEに対しては、Shift_JISでエンコーディングしてやれば正しく認識する（多分、UTF-8もOKな気はする）が。

追記：2047を適用すれば良いのかも。