猿頁

どぅもツールによる移植がうまくいかんなーと。
あちこちのいろんなC#サンプルをVBに変換かけてみたんですけど、ほとんどまともに動作する形になりません。

ってんで、可能な限りいろんなツールを入手、試してみました。

以下、試してみたツール一覧。

• C# to VB.NET Translator (Webページ)


• Convert C# to VB .NET (Webページ)


• CSharp to VB.NET Code Converter (Webページ)


• Instant VB (Windowsアプリ)


• Convert C# to VB.NET (Webページ)


• C-Sharpener For VB (Windowsアプリ)


• Free Code Translation for .NET (Webページ)


• Reflector for .NET (Windowsアプリ)

いや確かに中には明らかなうっかりバグだろうと思われる動作をするのもあるんですが。

そのうっかりっぷりがあちこちのWebページで見受けられるので、どぅやらこれらのうっかりっぷりな奴らは同じトランスファーエンジンを使っているんではないのか。んでもってこのうっかりエンジンが手軽に自分のサイトに組み込めるってんで普及とかしてしまっているんではないのか。

だからこそその状況を憂いたAlexさんが軽くギブ。→そしてTranslatorで引用したように俺んとこのはうっかりエンジンじゃねぇっ！と叫んだのかとよぅやく納得がいってみたり。

このへんどういうことかというと。

C#はVisualStudioの中で、もっともMSILに対して親和性が高いんです。
CLI/CLSうんぬんと関係ない部分まで親和性が高い。

たとえば、C#(C++もか)で

a = b = c = d;

a = (b = (c = d))

が、上述のツールではいずれもa = b = c = dとしてVBコードが出力されます。
(たしかひとつだけc = dとなりaとbが完全にどこへやら、というのがありましたが。)

逆に、VBの仕様はどのような形にせよ.NET Frameworkの上で実装されてMSILにコンパイルされますので、MSILと親和性が高いC#への変換はかなり高い確度で成功するわけです。

まぁReflector for .NETなどは開発意図として「はじめにMSILありき、VB/C#に置き換えて表示可能」というスタンスを取っているっぽい作りなので、「このMSILコードはVBでは表現できない」みたいなエラーが出るのも致し方ないと思いますが、「C#のコードをVBのコードにできますよー」な部分をウリにしているシェアウェア/商用ソフトなんかは、せめてこのくらいは

c = d
b = c
a = b

ZManがApril2005版のサンプルフレームワークのVB版を自分のサイトで提供してくれていることはなんてこったー！！！でお話ししましたが、実際に入手して使ってみると、どーいぅわけかソフトウェアレンダリングになってしまいました(；－；)。

のはやまやまなんですが、もうこれは

と腹を括って、人間の叡智をもってC#の最適解→VBの最適解へのトランスファーを試みるしかないかもしれません。

今回の検証で一番ツカえると思ったツールは、Instant VBです。
外貨シェアウェアなのでフルスペック版の入手が難しいのが難点ですが、プロジェクトごとかけてやるとクラスやオブジェクトの構造まで参照までして可能な限り正しく置換しようと動作するのはすげぇと思いました。

C#は「Device型の変数device」などと大小文字の違いだけで宣言しちゃってる場合がけっこうあって(C++からの流れかなあ…いいかどうかは別として)。
他のツールはほとんどステートメント単位の逐次解釈なのでこのへん全滅なんですけれども、Instant VBだけはそれなりに何とかしてくれました。

パーフェクトとは行きませんが、手動変換の手間が一番省けます。おすすめっす。

投稿者: さるべーじ 日時: 16:54 | パーマリンク | コメント (0) | トラックバック (0)

msdnサイト(米)のナイスコンテンツ、Coding4Fun。

私はこの中のAsk the ZManってシリーズが大好きで。
しかし当のDirectX SDKが9.0からC#とC++(Managedに至ってはC#のみ)のサンプルしかつかなくなってしまって。
当然SDKのSample Frameworkを下敷きにしたZManのコードもVBでは何ともできなくて。

やはりVBer(VB使い)としてはおもしろくないわけですよ。
なんとかSample FrameworkをVBへコンバートして、

とか言ってやりたいわけですよ。

で、今年の夏頃からソースコードを解析したりC#を学んだりC#→VBコンバート(トラスフォーム)ソフトやらページやらを片っ端から試したりいろいろしておったわけですよ。

今年のクリスマス3連休も子らの遊ぼー攻撃をいなしつつ一通りコンバート完了、ビルド時に出てくるバグをひとつずつ潰して、残エラー25までこぎ着けたわけですよ。
いやビルドが通りさえすれば完璧だと思っているわけでは決してなく、後はランニングさせながらのデバッグだと腹をくくっておったわけですよ。

そこまで自分なりにガンバって。

そんな時に見つけてしまった
　　DirectX SDK Sample Converting Effects to VB
そして
　　SDK samples in VB.Net

いや、The ZBufferは確かかなり前にチェックしていたはずなんだ。
時期的にはすでに上述のアーカイブはアップされていたはずなんだ。

もう明らかに自分のチェック漏れ、そして半年にわたる超遠回り。

あーーーーーーっもう！！！

投稿者: さるべーじ 日時: 03:11 | パーマリンク | コメント (0) | トラックバック (0)

といぅほど大げさなものでは。

本コンテンツは、Microsoft(R) DirectX(R) 9.0 SDK Update (June 2005)の続きでもあったりします。

前提として、ZManのソースとDirectX9SDK-Apr2005のサンプルフレームワークのソースは同一で、タイムスタンプも「2005/03/16 10:21:58」で同じだったんですが。

Jun2005のソースは、「dxmut.cs」と「dxmutmisc.cs」の内容に変更がかかっていました(タイムスタンプは「2005/05/20 00:08:02」)。
どぅも提供後に顕在化した不具合の修正といぅ感じで、機能の追加変更で修正されたわけではなさそぅですね。

ZManソースのCommonフォルダ内ファイルをJun2005版に差し替えて動作確認。
おっけー、イケました。

てことで、今回はこれ以降Jun2005版のフレームワークでの移植作業にしていくことにします。

あーめんどぃ。

投稿者: さるべーじ 日時: 12:18 | パーマリンク | コメント (0) | トラックバック (0)

ConvertCSharp2VBでも変換を試してみました。

つことで当分C# to VB.NET Translatorひと筋ってことでひとつ。

VBは大文字小文字を区別しないんだよぅ…(Ｔ－Ｔ)

このへんはミックスドランゲージソリューションとかC#/C++製DLLとかでいつも泣いていたりする部分なんですが。

Lower/Upper Caseを区別しない(abc = ABC)仕様はBASICの伝統なんですよね。
でもってVB IDEでは、宣言(または初回使用)した時の大文字小文字の組み合わせに自動的に直してくれるといぅお助け機能がついていまして。

例えば、

Dim intHoge As Integer
inthoge = 12345

なんてのがあると、2行目を入力して改行すると自動的に

intHoge = 12345

と、「h」→「H」と直してくれるわけです。
変数やらオブジェクトやらを必ず大文字小文字混ぜ合わせて命名し、実コードではすべて小文字で入力するよぅにすると、大文字変換されなければスペルミスとかスコープミスとか、そのへんのあぶり出しができて便利だったわけです。

C#はまったく経験がないのであれですが、C/C++の時は変数名や関数名の大小文字を間違っただけで別モノとして扱われるため、スペルミスなんかのあぶり出しがちょっとめんどくさかったんですよね。
もっともC/C++では未定義で変数や関数を使えませんから、コンパイル時のエラーからあぶり出せます。ので実害があるわけではないんですけどね。

おたがいそれぞれのいきさつがあっての現状ですから、ここを変えるわけにはいかないでしょう。
C/C++/C#の仕様を変えると過去資産の流用ができないケースが出てきますし、VBの仕様を変えるとプログラミングスタイルの変更を強制しなくちゃなりませんし。

つころで、今回はとりあえずPrivate型変数の方を「lDevice」に置き換えてしのぐこととしました。
外側に提供されない部分を変える分には影響ありませんしね。

投稿者: さるべーじ 日時: 12:15 | パーマリンク | コメント (0) | トラックバック (0)

こんな時間ではありますがネタが若干たまり気味になってきましたのでこの際ってんで連続で文章書いてるさるべーじですこんばんは今宵はまたお会いできましたね。

文章立て続けに書いていますので読んでいる皆さんにはなかなか実感していただきにくいとは思ぅんですが、実はもー3日も、仕事と家庭の合間を縫って必死こいて移植していたりしていたわけです。

3日ガンバって、未だひとつめのファイル「dxmut.vb」の2/3ですぜ。やってらんねぇっす。

こりゃぁまたあきらめちゃぅって手かなーとか思っていたんですが、ふと先日ひろ/Hさんて方(CLR/Hメンバー)が、C#→VBの変換サービスを提供しているWebページC# to VB.NET Translatorを自分の日記ページにメモ書きしていたのを思い出して。
その時は「ふーんこんなんもあるんだー」レベルの感想で、頭の隅に留めておいた程度なんですが。

この際少しでも効率が上がるんならいぅことないす。ちょっと試してみましょぅ。

いゃ実際これは大助かりですよ。かなりいい感じの変換コードを生成してくれます。
まぁ当然ですが100%の変換にはならないので、変換後に元ソースと突き合わせて修正入れなきゃならないんですが、それでも半日でファイル2つ消化できました。わーい。

• インデントが「3」。
  VBの標準は「4」なんですけど…技術屋って自分のスタイルにかたくななまでにこだわるからなー(含私)。
  まぁIDEにかけたとたんにインデントは整形かかるので不都合はないんですが。


• 「For i As Integer = 0 ～」とすべきところを、Dim文とFor文の2行に分割する。
  これはなんでなんだかちょっとわからないっす。For文の中にループ用変数の宣言を埋め込むとアクセシビリティがFor～Nextループの内側のみになるのに対し、その上の行で宣言しちゃうとそのプロシージャ全体になっちゃうので、びみょーにおかしなことになりそげな感じです。
  「i」とかを複数のFor～Nextループで使い回している時は重複宣言になっちゃぅんですけど。ここは気をつけて直しておくこと。


• プロシージャの引数の「ByVal」が付記されない。
  まぁこれもIDEに貼り付けたとたんに付加されるので実害はないんですが。


• プロシージャの最後、「End ～」の右側にコメントアウトでプロシージャ名を付加してくれる。
  実はこれはけっこぅ便利。私、自分でコード書くときにはこれやってます。
  C#のプロシージャやループやその他範囲の括りはすべて「}」で終わるので、実はちょっと見分けにくいんですよ。
  この「}」による括り終りはCの頃からそぅだったんですけれども。あの頃は構造化プログラミングがどーたらで「「}」の括り終りを見誤るほど長いソースを書くこと自体が悪だ」みたいな雰囲気があったんですが。
  実務上泥臭いコードを書くのなんて実は当たり前なんだ、と割り切ってからは「}」が大嫌いに。いゃ書き方としてはかっこいいんですけどね。
  もっともVBの「End～」だって五十歩百歩と言えばそれはそれでそんなもんなんですが。


• 並列の「Else If」が、Elseの中にIfを置く多重入れ子になる時がある。
  まぁ論理的には同じロジックですので動くんですけどね。なんだかスタックが膨れるのが怖いのは、私が旧世代のプログラマだからなんでしょうか。
  ちなみにその下にコメント文があると、End Ifの行に食い込んでしまうおまけつき。


• Try～Catchがあると、Catchの中のコマンドが全部落ちる時がある。
  例外の内容に応じてCatchが複数あったりするとどぅもダメっぽいです。


• #If文が完全に落ちる。その中身も落ちる。
  ふつーのIf文と解析ロジックは似たよぅなもんなんでしょうから、入れてくれてもいいのになぁ、と思う部分ですね。


• 型指定子つきリテラルの、型指定子が変換されない。
  たとえば左辺の変数の型をfloat→Singleに変換しても、右辺の「1.0F」はそのまんま。「1.0!」にしてほしいなぁ。


• Continue機能は2003までには存在しないため、ループの出口直前にラベルを置いて、そこへのGoto文に置き換えてくれる。
  2005にはContinue機能があるんだけど…とりあえずかなり複雑なIfの入れ子等でも適切にラベルとGotoを置くので、感心してみたり。


• 「///」→「'''」の置き換えがされず、「'/」となってしまう。
  xmlコメントも2003までなかったから当然なんですけど。


• uint→UIntegerの置き換えがされない。でもSystem.UInt32に置き換わる。
  これも2005からの新規格なので。


• using→Tryに置き換わる。
  これはある意味みごと。逆に私は、この変換ソースを見てよぅやくUsingの概念が把握できたといぅ。

This is NOT the same translation engine that is used at Kamalpatel.net. Try them both out and in some cases they will produce similar code but in many cases the engine used on this page is much better.
このサービスはKamalpatel.net(ConvertCSharp2VBの提供サイト)と同じ変換エンジンを使用しているわけではない。両方を使い比べてみてほしい。同じような結果になる場合もあるが、多くの場合はこのページの方がいい結果を出力しているはずだ。

まぁなんだか自信たっぷりげな言い分がいっそすがすがしく。

投稿者: さるべーじ 日時: 04:19 | パーマリンク | コメント (0) | トラックバック (0)

と思っているさるべーじですこんばんは。

だったらイジればいいじゃん、って思ぅでしょ？
その前にちょっと普及版のVB2005Expressβ2Jpをイジってみてからねー、なんて思ったのが運のつき。
けっこぅツカえるんですよこれが。
まだイジり始めたばかりなので細かい部分についてはなんともアレですが、とりあえず文法的にはあまり遜色ないみたいです。

まぁとりあえずはおもしろそぅなところからぼちぼちとまいりましょぅか。

前回さんざんじたばたしておきましたのでまぁなんとかなったのではないかと。

で、いよいよ「Applying Textures(part1)」のソースの移植をしよぅかと。

前回DLしたサンプルソースを展開してみると、「Textures0」と「Textures1」の2つのソリューションが出てきました。
今回はいちおぅ順番に「Textures0」から始めてみることにしましょう。

「Textures0」をC#2005Expressβ2でロードしてみると、こんな感じの構成になっていました。

なんだかやたらにファイルが多い…。

「とりあえず簡単にやってみよぅ」ってコンセプトのはずのコンテンツで、こんなに大量のコードを説明しているのかなぁ？

軽くファイルをいくつか覗いてみましたが、どぅもビギナー向けにどぅのといぅ内容じゃないぞどぅ見ても。特にCommonフォルダの中に入っている奴は尋常じゃねぇ。

って、dxmut.csのヘッダに「DirectX SDK Managed Direct3D sample framework」って書いてあるー。
ってことはこれ、DirectX SDKからの流用？

探してみたら、ありましたありました。
デフォルトでインストールした環境なら、「C:\Program Files\Microsoft DirectX 9.0 SDK (April 2005)\Samples\Managed\Common\」の下がそれだっ。

いやーまったくぴったり同じじゃありませんか。まいったなー。

てことは、ひょっとしてVB用の同等モジュールもあるんではないかしら。
と探してみたら、あったあった。「BasicHLSL_VBNET」とか、いかにもVB.NETソースっぽいサンプルが。これを開いてみたら、VB製のSample Frameworkのありかがわかるはず。
ちなみにDirectX SDKのサンプルソースはVS.NET2003用になっていますので、VBの方はVB.NET2003でロードしてみましょう。

いゃ意外なところで見つけてしまいましたミックスドランゲージソリューション。

なんてのんきなことを言っている場合ではないっす。

VB.NETのサンプルでもFramework部分はC#、ってことは、C#でしか提供されていないってことではないですか。

手持ちのVS.NET2003でやるんならそれでもいいですけど、今回はVB2005Expressβ2ってテーマなんですから。
Express Editionは言語のミックスを認めていないんですから。

「Textures」シリーズサンプルをVB2005Expressで遊ぶためには、DirectX SDKで提供しているSampleFrameworkまで全部自力でVBのコードに置き換えなきゃならん、ってことなんですかい？

…うーむ、しかたねえぇぇぇ。
やれるだけやってみることにしましょうか。

とりあえずVB2005Expressβ2で同じプロジェクト構造を作って。

ここにひとつずつ移植したソースを埋め込んでいけばイケるはず。終わるはず。いつかは。

くはー、なんだかとんでもない展開になってきちゃったなぁ、といまさらにして後悔中。

もーブン投げてしまいましょぅか。とほほ。

投稿者: さるべーじ 日時: 03:43 | パーマリンク | コメント (0) | トラックバック (0)

最近Microsoftの皆さんとかそのほかの皆さんとかから提示されるサンプルが、C#製になってきているよぅな気がしてしかたがないさるべーじですこんばんは。

こいつぁおもしれぇぜ、ってサンプルがC#製で紹介しにくいよぉってことが増えてきているんですよねー、雰囲気的に。

ここで「ではこれからはC#で」と言わないところがVBerの面目躍如といぅかやせ我慢といぅか。
C#とVBは構文的にほとんど1対1対応になっていますし、どちらかにしかできないなんてディープな部分はあまりサンプルの中では提示されないと思いますので、この際C#だろぅがJ#だろぅがいいサンプルはどんどん自分の肥やしにしていきたいと。

そんなところで、しばらく「C#からVBへの移植」で遊んでみたいと思います。

「For this article」の「Code for this article」からサンプルコードをDLして展開して。
C#2005Expressβ2とVB2005Expressβ2もそれぞれDLしてインストールして。
(実際には小さなインストーラ/ダウンローダをDL、インストールを開始してから本体のDLが開始されるので、インストールにはインターネット接続環境が必要となります。)

インストールの最後に「30日以上使い続ける場合のライセンス認証用のコード」も取得、きちんとそれぞれに登録して。

あとでどぅこぅ言われるのが嫌なので、2005β2で作成したコードの再頒布権Go-Liveライセンスも取得して。
(あらかじめMicrosoft Passport Network/.NET Passportへの登録が必要です。)

さて、まずはTextures0プロジェクトからどんなもんか見てやるー。

….NETに対応したmaneged DirectXが要るんでした…。

気を取り直して、DirectX 9.0 SDK Update - (April 2005)もDLしてインストールして。
再頒布モジュールでは開発用にはちょぃとまずいだろぅってんで、152MBもあってしんどいんだけれどもSDKをチョイスして。

ついでだけれどもDirectXのTopページ、DX9.0SDKヘルプ、DX9.0SDKヘルプ(Managed)とかもチェックしたり、DirectX9.0SDK Update(October2004)日本語ドキュメント(こいつも48MBもありますが)もDLして手元に置いておくと便利かもしれません。
まぁ日本語ドキュメントについてはちょっと古いのがあれですがおおまかおっけーといぅことでひとつ。

DirectX SDKのインストール中に、「Visual Studioのツールバーが初期化されちゃうけどいいっすか？」ってダイアログが出てきました。
「別にいいやー」って[Yes]ってやったらこれが大失敗。
同じマシンにインストールしてあるVS2003で、独自のツールバーを追加するIDEのAdd-In、MZ-Toolsが起動時にエラー起こすよぅになっちゃって。
あわててアンインスト→インストかけ直したら、独自に作ったテンプレートが全吹っ飛び(Ｔ－Ｔ)。
ツールバーをどぅこぅするよぅな拡張をしている場合には、一度取り外してからインストした方がいいっすよ。

しかも別にDirectX用のツールバーが追加されるわけでもなし。
なんでツールバーを初期化するんだろぅ？これなら[No]選択でもよかったのかも。

まぁいいや。

ここまでやったらmsdn Libraryも起動して。ってこれはVS.NET2003 IDEから[F1]押せばいいんですけど。「ヘルプ更新を実行中」のダイアログが出るのでしばらく待って…あれ、ダイアログは消えるけどその後DocumentExplorerが起動しません。
なんべんやっても「ヘルプ更新を実行中」→おしまい。

おおっ？

しかたがないのでスタートメニューから「MSDNライブラリ-2005年4月リリース」を起動。
ってこれではMSDNライブラリしか表示されませんね。
もとい、調整したいのはVS.NET2003 IDEから起動した時に参照される「Visual Studio.NET連結ヘルプコレクション」の方のわけですから、この起動方法じゃだめっすね。
しかたがないので「ファイル名を指定して実行」ダイアログからDocumentExplorer直起動。(私の環境では「C:\Program Files\Common Files\Microsoft Shared\Help\dexplore.exe」)

おぉ、これでDirectX9.0(C++/Managed)がよぅやっと追加されたぞ。
って、日本語版の方のコンテンツが表示されない…。

こんな時には「Visual Studio.NET連結ヘルプコレクションマネージャ」で連結する項目を指定し直してやればいいのだが、コレクションマネージャのページへのリンクがものすごく見つけにくいのは先日どこかで記述した覚えが。

こんなこともあろぅかと、DocumentExplorerの「お気に入り」にコレクションマネージャのページを登録しておいてよかったー。
そんなことをしていない方は、この際やっといた方がいいよぅな気がします。
URLは「ms-help://MS.VSCC/vscccommon/cm/CollectionManager.htm」ですんで。

よぅし、「DirectX9.0JPN」の選択肢があることを確認、チェックをつけて。
「Visual Studio.NET連結ヘルプコレクション(VSCC)を更新する前に～」ダイアログが表示されるので、[OK]押して次のダイアログでもう一度[OK]押して。
DocumentExplorerを終了して、もう一度直起動して。
「ヘルプ更新を実行中」ダイアログが表示されて→DocumentExplorerが無事表示。

目次に「DirectX9.0SDK Update(April2005)」と「DirectX9.0SDK Update(October2004)日本語」が並記されているのを確認してもう一度終了。

で、今度はVB.NET2003 IDEを起動して、その中から[F1]でヘルプを起動。
おっけー！DocumentExplorer単体起動時と同じ目次になったぞ！

ついでだが、今までさんざん起動に時間がかかっていたのが、今回の操作後、むちゃくちゃ起動が俊速になってしまったのはどーいぅわけだ。

…あ。
今回のテーマは「VB2005β2でうんぬん」なんだから、そっちのコレクションを確認しなけりゃ意味ないんですよ。orz

2005β2をDL/インストした際にヘルプも一緒にDL/インストしたんですが、こっちのDocumentExplorerのバージョンは「8」()。VS.NET2003 IDEやmsdn 2005.04で使用されるDocumentExplorerのバージョンは「7」なので、VSCCが別なんでした。

で、こちらもコレクションマネージャのページが見つからないったらありゃしない。
半べそかきながらあちこちいじりまわし、よぅやく見つけましたよ「ms-help://MS.VSExpressCC.v80/dv_vsexpcc/local/CollectionManagerExpress.htm」がそれだっ。

で、そのページを開いてみると、なんと赤バッテンメッセージボックスが。

「Cannot find the Visual Studio 2005 Express Combined Help Collection.」
「Cannot find the plug-in list of Visual Studio 2005 Combined Help Collection.」

ごていねいに2つも(Ｔ－Ｔ)。

ヘルプコレクションも見つからないし、編集用のプラグインのリストも見つからないって。
てことでせっかく見つけたマネージャページですが、

「Collections available for inclusion in VSExpressCC」(VSExpressCC に含めることのできるコレクション)が空っぽ。当然[Update VSExpressCC]もEnabled=False状態で。

このページのVBSをたどってみると、どぅもレジストリのHTMLHelp NameSpaceListを取得して、その中に「MS.VSCC.V80」がない、といってエラーになってるらしいっす。
んですけどもこれってExpressではない本家msdnLibrary(VS2005用)をインストールした時に入るもののよぅな気がするなぁ。
実際に本家VS2005β2(+msdnLibrary2005β2)をインストしてみれば動作するかどぅかはわかるんでしょうけど、今しばらくExpressだけで遊んでみたいので。

つことで以降は次回。ふぅ。

投稿者: さるべーじ 日時: 22:06 | パーマリンク | コメント (0) | トラックバック (0)