アーカイブ

2006年 5月 28日 のアーカイブ

真魚でやっている文字コード変換をVB.NETへ移植する計画が進行中。
VBがぜんぜんわからないので、まずはC#へ移植して、そのあとVBでもやってみる。
ほいで、C#への移植までは出来て、変換テーブルがあるので200KBほどのサイズだった。
ようやくVBに取りかかったのだが、予想以上に多くの障害を感じている。

まず、VBって初心者用だからなんだろうが、難しい部分は隠蔽されている。
C#もVBも、今回の2005からpartialという識別子が出来て超便利になったのだが、
そのpartialで、デザイナの仕事を別ファイルに保存していて、
C#ではその別ファイルがプロジェクトに含まれているのに、
VBではそんなファイル自体ありませんよとでも言うかのように、一切表示されない。
確かに、そのファイルは開発環境が自動的に書く物であり、
プログラマがそのファイルをいじる機会などはじめからないのでそれで良いのだろう。
そのファイルをみてVBの書き方を覚えようとしていたので、アクセスできなくて最初は迷った。
定義を検索とかすると結局そのファイルにはたどり着けるんだけどね。

次に、改行の扱いが特殊で、気がつかなくてずいぶん悩まされた。
VB.NETでの改行は、文の区切りを意味するんだな。
だから、二行以上にまたがる文を書くときは、アンダースコアでハイフネーションを行う。
他の言語ではセミコロンがない限り、何行にでもまたがる事も出来るので、
まったく思いもよらず、しばらく迷い続けた。

で、作業としてはまず、Char配列でテーブルを作るわけだが、
これもChar型を16進数で定義するにはChrW()関数を使わなければならず、
たかが定数なんだから関数なしで定義したくて迷い続けたが、それは結局出来ないらしい。

決定的な弱点として、定義した名前空間が、デフォルトの名前空間の子になってしまう。
そもそもVBは名前空間など意識せずにやれと言うことなのだろう。
覚えなくて済む部分は徹底的に隠蔽して、出来ることは簡単に出来るようにという方向だ。

ということで、VB.NETがターゲットとしている層は、予想よりもっと初心者よりだった。
いや、ズブの素人相手であることはわかっていたが、
C#をやった人にとってこれほど不自由な世界だったとは思わなかった。
やはり、昔のVBがそうであったように、専門的な仕事をするDLLは別の言語で作り、
部品さえ集まれば何でも好きな物が作れるって環境を目指してるんだろうな。

そういうわけでね、文字コード判別DLLはC#で作ってC#のソースを添付し、
サンプルとして、VBのプロジェクトからDLLを使って見せるソースを用意しようかな。
C#が出来る人はC#のサンプルなんぞなくたって使えるだろうよ。
VBから使ってみせればC#でも使えることはすぐわかるだろうよと。
さらに、DLLのソースを必要とする人間はVBじゃなくてC#をやるだろう。
ソースが付いていても、ありがたいと思えるのはC#ユーザーの方だろう。
といった現在の見解。
この選択肢の中にDelphi.NETとかVC++.NETとかJ#.NETとかはもちろん入ってない。
続く。。。