プログラミング：その他

CSVのRFC

αετος / aetos — Fri, 13 Mar 2009 02:55:00 GMT

2005年10月、RFC 4180が発行されています。
タイトルは「Common Format and MIME Type for Comma-Separated Values (CSV) Files」。いわゆるCSVファイルのフォーマットを記したものです。
これは、分類が「Informational」ですから、「規格」とは言い難いかもしれません。
「もし今後、CSVを扱うソフトを作ることがあったら参考にしてね」という程度のものでしょうか。

さて、この中に「あれ？」と思う一文があります。
2.4 The last field in the record must not be followed by a comma. というのがそれです。
日本語では「レコードの最後のフィールドの後にコンマが続いてはならない」とでも言いましょうか。
つい「最後のフィールドはコンマで終わってはならない」と意訳しそうになりました。

[続きを読む]

More Exceptional C++

αετος — Wed, 26 Nov 2008 17:08:00 GMT

More Exceptional C++ さらに40のクイズ形式によるプログラム問題と解法 (C++in-Depth Series): ハーブサッター, Herb Sutter, 浜田光之, 浜田真理: Amazon.co.jp: 本

日本語版でてた。

snprintf

シャノン — Fri, 05 Sep 2008 11:33:00 GMT

int snprintf( char * s, size_t n, const char * format, ... );
という C の関数がある。C99 から標準に加えられたものだ。
名前から想像できると思うが、s で指定したバッファに、format に従って書式化した文字列を最大 n 文字書き込む、というものである（この説明には語弊がある。詳細は後述）。

VC++ には、_snprintf という関数がある。
引数は標準の snprintf と同じだが、関数名の先頭がアンダースコアであることからもわかるように、これは C の標準関数ではなく、VC++ の独自拡張関数である。VC++ は C99 に対応していないためだ。

この２つ（標準の snprintf と VC++ 独自の _snprintf）は、ある一点において挙動が異なる。
それは、書式化した文字列の長さが n 以上だった場合である（ここでは、他バイト文字は考慮せず、1文字1バイトとする）。

標準は、n - 1 文字まで書き込み、最後にナル文字を付加する。つまり、n = 0 でない限り、出力はナル終端されることが保証される。
VC++ 版は、結果の長さが n 文字未満である場合のみ、ナル文字が書き込まれる。
これは、strncpy と似た挙動であると言える。

どちらが安全かと言えば、標準の方だろう。バッファオーバーフローが大きな問題として取り沙汰される昨今、新しく追加する関数はより安全なものにしておくという判断は分からないでもない。
だが、できれば既存の関数（strncpy）と挙動を合わせて欲しかったと思う。
いや、こんなことを考えるのは、俺が今、ナル終端しないでバッファいっぱいに書き込む必要があるようなシステムを作っているからだというのも、そんなのが異端だということも分かってはいるが。

ちなみに、VC++ 2005 から取り入れられたセキュリティ強化バージョンである _snprintf_s は、書き込むバッファのサイズと、バッファに書き込む最大文字数を別の引数として取り、バッファサイズが書き込み文字数 + 1 以上でなければエラーになる。
従って、バッファには常にナル文字を書き込むスペースがあることになるので、この関数は、指定した最大文字数に加えてナル文字を書き込む（書き込む文字数 + 1 文字が書き込まれ得る）という動きをする。

そういえば、Microsoft は _s バージョンの関数を標準案として提出したという話も聞いたような気がするが、そっちはどうなってるんだろうなぁ。
あと、これは全く余談だが、_lsearch_s は全然セキュアじゃない。

IDE なんて要らない

シャノン — Mon, 01 Sep 2008 10:34:00 GMT

エディタとコンパイラがあればいい。そういう人がいます。
VB6 以来の IDE っ子である俺は、今まで、「新しいもの嫌いが何を気取ってやがる」と思ってました。

が、ふむふむ。
なかなかどうして、やってみると、これはこれでなんとかなるものですな。

いや、ほら。
今の開発が Linux 向けなものですから、VC++ を使うわけにはいかんのですよ。
慣れ親しんだ Windows 上で、インテリセンスの効かないエディタでコードを書いて、FTP でサーバに転送して、makefile 経由で gcc でコンパイル、の繰り返しです。
全部サーバでやるのはちょっと…vi じゃ使っていてイライラしますし、今から Emacs を覚える気にもならない。
まぁコンパイルとリンクを別々にやってるわけじゃないので、いわゆる「エディタとコンパイラ」の要件は満たしてない気がするのですが、今時そんなこと、いくら Unix 使いでもやってないでしょう。

まぁそれでも、色分けできるエディタは最低限必要ですな。あとホイールマウス。

サーバ運営のハードルは下がるのか？

シャノン — Mon, 01 Sep 2008 01:16:00 GMT

本当にいろんなことが、パソコンでできるようになりました。
文書が作れる、絵が描ける、音楽が聴ける、DVDも観れる。
初音ミクはDTMのハードルを大きく下げたと思います。それでも作曲のサの字も知らない俺のようなやつが買っても手に余るだけだと思いますが。

そして、我らがマイクロソフト！　Visual Studio Express Editions なんてものを出してくれたおかげで、プログラミングまでタダでできるようになっちゃいました。
プログラミングなんて、本業でない人がやるものの中では、マニアックさでは上位に入るものではないでしょうかね。
いや、素晴らしいことです。

そんなマイクロソフトさんに、ぜひ次に頑張ってほしいのが、サーバ運営のハードルを下げることです。
要するに、趣味で自家サーバを立て易くしてくださいと。

もちろん、現状でも自家サーバを安価に立てることはできます。
Unix で Apache 使うとか、Windows 用でも無料の Web サーバソフトはあります（サーバ OS じゃないと接続数制限があったっけ？）。

でも、ほら、どうせなら、マイクロソフトさんが宣伝している最新の IIS でもって、ASP.NET とか WCF とか駆使してやりたいじゃないですか。
そういう本はよく出てますし、セミナーも積極的にやってくれてますけど、レンタルサーバだと使えないことが多いし。
Windows 2008 には Web Edition なんてのがありますが、やっぱりお値段がね。趣味では買えない。
どうもこの領域は高止まりしている気がします。
いやいや、難癖付けてるつもりはないんですよ。
もちろん、それ相応の機能制限はあって当然でしょうとも。

さて、一方、仮にマイクロソフトが英断を下して、そのあたりを気軽に使えるようになったとして、使う我々の側はどうなのでしょう？
最初にも言いましたが、いくら初音ミクが出たからといって、誰も彼も作曲ができるようになるわけではありません。
Visual Studio Express Edition だって、入手することは誰にも可能であるものの、誰にでも使いこなせるわけではありません。
そのへん、サーバ運営は？

ちゃっぴさんのところでおあつらえ向きな話題が上がってたので絡めますが、サーバ開発の経験がない俺からすると、Java や C# のような（広義の意味での）マネージ言語で作っても、いろいろ気をつけないと、あっという間にスーパーハカーの標的にされてウィルスばら撒くことになるんじゃないかなんていう漠然とした不安があります。
最近はクロスサイトナントカっていうのもよく聞きます。
マネージ言語を使うことでバッファオーバーフローの危険がなくなった（ゼロになったと言うと突っ込まれそうだな）ように、最近の開発環境ではクロスサイトナントカも低減できるようになっていたりするんでしょうか。

Windows SDK Configuation Tool が使えない

シャノン — Sat, 30 Aug 2008 21:15:00 GMT

Windows SDK for Windows Server 2008 and .NET Framework version 3.5 をインストールするとスタートメニューに追加される Windows SDK Configuation Tool ですが、GUI で立ち上げるとインストール済みの SDK のバージョンが出てこない。
で、コマンドラインでも実行できるのですが、インストール済みのバージョンを一覧表示する -version コマンドや、現在のバージョンを表示する -current コマンドを使うと例外で落ちる。

原因は、例外のメッセージからおおよその見当が付いていましたが、バージョンナンバーの扱いにあります。
このツールは内部で Version クラスを使用しているのですが、Visual Studio 2008 日本語版と一緒にインストールされる Windows SDK はバージョン 6.0A というやつなのです。
Version クラスは "6.0A" なんて文字列を有効なバージョン番号とみなさないために落ちている、ということですね。

内部的にやってることは、レジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows の CurrentVersion と CurrentInstallationFolder を設定しているだけなので、regedit.exe でこれらを設定してやれば同じことはできます。あ、64bit OS を使っている場合は、HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows も更新してくださいね。

しかしこれは… SDK Team が "6.0A" なんてバージョンが出てくるとは思ってなかったというか、今でもそんなバージョンがあることを知らないということなんじゃないかなぁ。

ローマ字も標準化してくれないかな

シャノン — Tue, 05 Aug 2008 19:06:00 GMT

マイクロソフト製品ならびにサービスにおける外来語カタカナ用語末尾の長音表記の変更について

マイクロソフトが長音の表記ルールを変更したというニュースはまだ記憶に新しいところです。
俺はこの件についてはコメントを差し控えます。

ところで、マイクロソフトはアメリカの企業ですから、ローマ字表記なんて使わないでしょうが、日本でシステム開発をしている皆さんはどうでしょう？　変数名やコントロール名にローマ字表記を使っているでしょうか？

全部英語にするという人もいるかもしれません。
が、英語に不慣れな我々がやると、ましてや業務固有の用語などは、どうにも不自然な訳になってしまいがちです。
そのため、俺はローマ字容認派です。

日本語（漢字かなカナ混じり）で名前をつける人もいるかもしれません。
やめろとは言いませんが、俺は嫌です。
IMEをONにしないとインテリセンスさえ出ないのはものすごくイライラします。
まぁ、えっと…何て言うんでしたっけアレ、ローマ字タイプでインクリメンタル変換してくれるやつ…が搭載されればいいのかもしれませんが、難しいかもしれませんね。

閑話休題。

ローマ字の難点は、表記のゆれがあることです。
例えば、「状態」は「Zyoutai」か「Joutai」か。「Jyoutai」なんてのも見たことがあります。
「調査」は「Tyousa」「Chousa」「Cyousa」のどれでしょうか。
「開始」は「Kaisi」でしょうか、それとも「Kaishi」でしょうか。
長音は省く場合もあります。「東京」が「Toukyou」ではなく「Tokyo」になるように。
これらはあらかじめ決めておかないと、プログラミング段階になって混乱します。

こういうのも、どこかが指針を作ってくれないかな、と思うんですけど…そう思いませんか？

ぐぐっても出てこなくなったなぁ…

シャノン — Fri, 18 Jul 2008 18:52:00 GMT

VB6の資料orz

何の冗談でしょうか？

シャノン — Tue, 10 Jun 2008 19:12:00 GMT

VB6なんですけど。

グリッドコントロールを使わないで、ラベルと Line で擬似グリッドを実現するってのは…。

フォーカス制御も全部自前。データバインドなんてありません。ADOっておいしいんですか？
サーバ側プロセスが DB からデータを取ってきて、それをソケット経由で受け取って、クライアント側でゴリゴリ編集して、サーバ側プロセスにソケットで送り返して、サーバ側プロセスが SQL 組み立てて DB に書き込みます。

「うわぁ、プログラムってここまでひどく書けるんだ…」みたいな感じがしてきました。

…逃げていいですか。

続・何年かぶりにVB6

シャノン — Fri, 06 Jun 2008 17:27:00 GMT

久しぶりにVB6をさわったら、既定のインスタンスが大好きになってしまいそうです。どうしよう。~~これが恋？~~
コメントにしたら長くなりそうなので~~円取り立てました~~エントリ立てました。

いわゆる業務アプリ開発において。
画面がいくつかあるとします。
画面遷移図が木構造になっておらず、AからB、BからC、CからAという遷移が可能だとします（BとCを通ってAに戻るイメージです）。
木構造ならモーダルフォームで楽が出来るのですが、このように輪になっているとそれはできません。
こういう場合、次に表示する画面を毎回 new するわけにはいかないので、一度作った画面のインスタンスは、遷移元画面クラスの外に置かなければなりません。
既定のインスタンスは、それを暗黙のうちにやってくれるものと言うことができます。

VB6.0 で「Form の既定のインスタンス」を防ぐには?

防ぐなｗ

このような、正当な方法を利用するメリットはいくつかあります。

インスタンスを生成することで、初期化が保証される
スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
結果、他の場所から勝手に呼び出されてしまう心配がない
外部のどこから操作されているのか明確になる
別のインスタンスを作って複製可能

ふむふむ？

インスタンスを生成することで、初期化が保証される
- 既定のインスタンスを使うと初期化されないんですの？
  既定のインスタンスのメソッドを最初に呼んだ時に Initialize が走るって書いてありますやん。
スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
- それじゃ狭すぎて困るんです。遷移元画面よりも広いスコープが必要なんです。
結果、他の場所から勝手に呼び出されてしまう心配がない
- それはそうかも。
外部のどこから操作されているのか明確になる
- どこかで一元管理しているなら別として、遷移元画面で new しているような状況では、そんなに変わらないと思いますが。
別のインスタンスを作って複製可能
- 実のところ、同じ画面のインスタンスをいくつも作る必要がある場合というのは、そう多くないものです。

画面管理クラスをちゃんと設計して、遷移元画面から直接次の画面を Show しないように作るのが正道かもしれませんが、理想と現実は得てして異なるものです。
# 100以上のフォームを、「動かなくてもいいから、とりあえず今日中に画面遷移だけでもするようにしてくれ」って昼過ぎに言われてもね…。