先日書いたC#のソフトをVB.NETに変換した話、画像の拡大縮小にかかっている時間がC#とVB.NETでやたら違う (両方ともOptimizeONにてコンパイル)、画像ビューアでWindowをリサイズするとそのサイズに合わせて拡大縮小しているのだが、C#で作ったものがほぼ一瞬でリサイズ・再描画完了している(Nativeで書いたのと(感覚的にだが)似たようなレスポンス) であるのに対しVB.NETでは0.5秒程waitがかかり、JavaのSwingのレスポンスを見ているようなカンジ(あくまで感覚的にだが).

実際のexeのコードをReflector(.NET向け逆コンパイラ) で覗いてみた所VBのコードでは言語の仕様上整数型の代入の部分でMath.Roundが呼ばれており、先のコードはC#で書かれたものである為Fixの呼び出しと合わせてRound( Ｆｉｘ(n) )という呼び出しになっており2重の関数呼び出しのオーバーヘッドが効いている模様、うーむ:-<

VB.NET用にFixを除去したアルゴリズムでも整数型への代入は常にRoundを経由する辺りも含めVB.NETではC#よりも整数-浮動小数の変換が意外とコスト高になるという所か.

# 余談だがC#でSusieプラグインを使って画像を呼び出すライブラリを作った時は正直むしろC++の方が楽だと感じた、メモリアドレスと配列・構造体が(何もしなくても)相互変換可能な部分. なおC#のコードを上げてからC++のコードを書いたが作業用バッファの明示的解放やリソースの寿命管理が明確にできる辺りC++の方が逆に気持ち良く感じたのは何としたものやら :-P

# しかし.NETだとホント中身丸見えになるなぁ、殆ど実際のソースそのままだし＞逆コンパイル結果(笑、、、って余り笑えないが:-<

# ついでにMath.Roundが標準で銀行丸めである事に気付く、所謂普通(?)の四捨五入にする場合はMidpointRounding.AwayFromZero(長っ)を指定するのだそうな、勝手に丸め程では無いけどこれも勘弁して欲しいなぁ、まぁ実際には浮動小数点数の計算過程で0.5なんて切りの良い数をアテにして組む事はまず無いので量子化データの整数化のみの用途 (これはBankers Roundで良い) と考えると実害は無いとは思うが、ついうっかりみたいな話がありそうでどうにも気持ち悪い、、、sign (あくまで主観だけど)

# C#のchecked構文は整数型のオーバーフローチェックのみで、浮動小数点数のオーバーフローや無効演算など浮動小数例外を検出してくれる機能では無い模様、浮動小数点プロセッサのフラグをいじれば良いのだがクラスライブラリに用意されていない&関連情報も見当たらない事から正式にはサポートしていないのだろう、フレームワーク層が厚い為無理矢理割り込みONにするのは危険そうという事で断念、アルゴリズムのチェックには意外と便利なのだが、残念 :-<

---------------

追記)

ただReflectorのIL以外の各言語での出力は参考程度で必ずしも実際のexeのコードと等価とは限らないと考えた方が良いかもしれない、C#で三項演算子で書いている個所がIIF関数で出力されているが、IIF関数は真偽に関係なく全ての引数を評価するので、実際にはReflectorで出力されたVBのコードは完全にILと等価にはなっていない(この場合ILでも条件でのジャンプ命令になっているのでC#の出力が正しい).

まぁそれでもコードの再現性は非常に良いのだけど.

戯れにSharpDevelopの機能を使ってC#で書いたコードをVB.NETに変換、大文字小文字の区別のせいで名前の重複などに悩まされるも比較的に安易に変換完了、、、と思いきや、画像処理クラスの出力結果が変、1時間程悩んだ結果原因は以下のような話

Dim a As Integer = 10
Dim b, c as Integer

std.printf("%g" & vbLf, a/6)    '->1.66666666666667 ...(1)
a=a/6
std.printf("%g" & vbLf, a)      '->2 ...(2)
b=c=a
std.printf("%g:%g" & vbLf, b,c) '->0:0 ...(3)

(1)は整数型宣言されていても演算過程で除算は全て小数になるというもの、まぁその為の\演算子なので致し方無し.

(2)は、、、マジで勘弁してというカンジなんですけどorz 勝手に四捨五入&所謂Bankers round (2.5が2になる) というヤツだが、言語レベルで全ての型の丸めにこれが使われている為細心の注意を払わないと演算系のコードの移植が難儀過ぎる、、、sigh

(3)はどうやら代入では無く比較比較演算として扱われている模様(代入は「文」扱いなので並べた時点で式として解釈されている)

何となくVB系列がちょっと嫌いになった出来事 (特にというか限りなく(2)が大きいが) というか演算系は手抜きしないでその言語ごとに設計・検証しないと怖いね、、、:-<

# そして変換後のVB.NETのコードを見て単語が多くて目がチカチカする、とまた毎度のごとくブチ切れるワケであります(苦笑)

---------------

そういえばJScriptはManaged JScriptとしてDLRに乗るそうな、.NET SDKに付属のJScript.NETとは別物、というかこちらはやはり見捨てられたかな? 確かに.NETのライブラリ設計が比較的引数の型によるオーバーロードを多用していた為型推論は融通が効かず、動的言語としてのメリットはほぼスポイルされており、しかも周辺環境まで含めるとC#の方が組みやすいようなシロモノであったが、、、うーむ.

IronPythonやその他諸々アナウンスはされているけど、中長期的には果たしてどうなるやら:-P 意外とこの手のオリジナル以外のクローンポーティングって、ノリに乗っている時は華やかなのだが、その後長期的に常にオリジナルと追従させようとすると、枯れたものやある程度独自仕様が許容されるシンプルなもの位しか安定してモノになってない気もするのだが(かつてJVMで動く言語が沢山アナウンスされ、また最近はJVM上のスクリプトが現れては消えているようなカンジ、例外はJavaScriptだが、これはコアの規模は小さいので)

余談だがSunのJRubyサポートはいつものMS嫌悪 (一応IronPythonだけがアナウンスされDLRの話が表に出る前の頃のアクションだし vs Pythonっぽく) としての反応なのではと邪推してみたり、何ともSunのJava戦略だけは(経営戦略的な観点からは)よーわからん、かといって(旧来の意味での)OpenSource系に貢献というワケでもなし、はて?

100ドルPCプロジェクト、最初の1000台製造に成功

これ良いな、発展途上国向けだけで無く我々の社会にもこういものがあって良いのかもしれない.

以前から現状ではコンシューマベースでLinuxがWindowsを置き換える事は難しいという主張をしてきたが、もしその予測を覆し得るとしたらこういうものになるかもしれない、無論インストールベースとしてOffice互換ソフトやブラウザ、メーラなどがワープロレベルでプリセットされており、コンピュータに興味の無い人間がワープロレベルで使えるという条件があれば.

また素晴らしい所は衝撃や埃などへの耐性を重視しているという所か、情報が記載されていないので詳細は不明だが、子供の玩具と同レベルの乱雑さで扱って耐えうるものであれば実に良い、現状のコンピュータはデリケート過ぎてうっとおしい;-P

100ドルという価格は (コンピュータに興味が無い人間としては) まだ決して安いとは言えないものの、ある程度の耐久性が認められるなら消耗品として買っても良い程度の値段ではある、何よりそういうものがごくありきたりになる未来は面白そうではある、コンピュータは所詮道具であり位置付けはせいぜい文房具程度でしかない、身構えて使わねばならないものである時点で道具としてはまだまだ未熟なのだと思う.

# まぁ別議論としてそんなプラットフォームでまともな(エンドユーザー指向の)ソフトが出てくるかという議論はあるにはあるし、またハード屋にとってやってられるか的な要素もある事は確かだが、、、:-<

---------------

先月末から(自主的に)続いている.NET集中講義もほぼ3週間目、朝から晩までコードを書いており、最近ようやく自分の身になってきたカンジ. まぁ現状身動きできぬ状態である為、良い機会ではありこれもまた良し.

なお今現在の結論としてはよく出来たVB6の代用品、VB6よりポテンシャルは高くまた配布の懸念はやや大きい、C++ + APIに比べると自由度は低くAPIの自由度に比べるとクラスライブラリの詰めも甘い(※1)がVC++でMFCだけしか使わない程度の用途なら代用する価値は十分ある、パフォーマンスの問題もよく反対意見として言われる程シビアな例は稀で下手な組み方をしなければそこそこ中規模程度までで対話的操作の粒度が荒いものであれば問題なし、ただそれ以上でもそれ以下でもなしという所. 人月単価50万とかのふざけた仕事をさっさと処理する場合 (そんな仕事は受けないのもアリだが) や内部ツールなど数年規模に渡って継続的メンテの必要が無い程度のものなら十分使う価値はある、但し大規模配布クライアント向けには値段etc.含めフィールド屋と要相談だが、数十人規模の中小には全然問題無いという印象.

※1) なお先日書いたGDI+標準の拡縮については結局使い物にならぬ事が判明、詳細はまた書く予定だがおよそ万事この調子のMSクォリティではある;-)

なお誤解の無いように書いておくとMS製品の全般的な品質が低いという話では無く (実際Officeなど規模のQAをこのレベルでやろうとするのは極めて難しくMSは実に良くやっていると思う) それを専門に扱う人間の求める機能からすると詰めが甘く結果的に門外漢のエンジニアが仕様あるいは教科書通りに取り合えず仕上げました程度のモノで使い物になっていないというだけの話 (例: Excelの誤差の扱いや申し訳程度の(高等以上の)数学関数とか、GDI+のgamma補正なんかも然り、またGDIの根本設計でベクトルを扱う場合の精度の低下、分かり易い所ではWordでのレイアウトの(専門のソフトと比較しての)お遊び程度の実装etc. .NETに限定しても先の拡縮の話に入力フォーマットでしか保存できない画像エンコーダ、既に減色済みの画像を勝手にディザリングするGIFエンコーダにAPIに比べて圧倒的に乏しいプロセス間通信の機能 (結局APIを呼び出す) ポートを1つ占有するしかない.NET RemoteにユーザーにXMLを強要するしかない設定ファイル (プログラマならいいけどね)等々 MS製品はほぼ万事この調子ではある、似たような所ではLWのIKやIrradiance Cache実装にも同じようなにおいを感じたけど ;-P

引き続きC#

.NETライブラリのArray/List.ConvertAllが使い辛かった (ArrayやList<>に限定した引数のみでIEnumerableを受け取ってくれない) という事でmap, reduce, filterなどを書いてみた.

string[] clist = std.map < ListViewItem, string > (listView1.Items, delegate(ListViewItem n){
    return n.Name;
});

、、、何だこの例えようの無い敗北感はorz

# 引数をIEnumerableにしている (Tree/ListViewなどコントロールのコンテナにも使いたい) 為、Genericの型引数を推論してくれないので馬鹿みたいに長くなって全然嬉しくない & 無名関数の引数が親スコープの変数名と重複させるとコンパイルエラーになる為変数名も気を遣う X-<

---------------

エクスプローラはあれから外部ファイル操作での削除・追加の同期機構とファイル作成などでのちゃんとした表示の整合性維持 (勝手に毎回リロードしたりせずフォーカスなども保持する) + 最低限のファイル操作(ドラッグ&ドロップはまだ) を実装した状態でメインフォームが450行程度(※1)

C#での開発効率は確かに良いが逆にライブラリの機能が無い場合の不便 or 安直であるが故の落とし穴もあり、また設計のサイクルは効率化できるものの設計粒度はC++と変わらずという具合なので、諸手を上げて良いとも言えず、今の感想ではあくまでBASIC程度 (但し配布を除けばVB6よりははるかに良い) というカンジ、うーん.

やっぱり私みたいな間抜けの底上げをやってくれる銀の弾丸ってのはそうそう無いものですかねぇ、例えるならモップかけとか水汲みとかやって数時間座禅を組んだら何時の間にかプログラムがバリバリ書けるようになっている、みたいなのが理想形なんですが orz

※1) 実際行数でソフトを計るのは馬鹿げている、あくまで同様のものをC++で作った場合の対比と第三者がソースを読む場合のコストの指標程度の話、なおネットでソースコード行数の話題に対すしてのレスなど見ていると、平均的なプログラマの1日の生産行数 (コピペでは無く) は500行程度という回答が多い気がする ((これも厳密には規模が増えると指数関数的なコストの増大を示すが) 、仮にそれが正しいとしてソースコードは書くよりも読む方が一般に難しいので、1日に読んで200〜300行程度と見積もった上で (あくまで仮定) ソフトウェアの開発費及び、完成後のメンテナンスコストを考え損益分岐点を考える、また平均的に調達 (嫌な響きだ) できるエンジニアのスキルを考慮した上で (複雑なソフトは人の数を増やしても駄目で、結局優秀なエンジニアにしかメンテナンスできない為、開発者が延々メンテするとするとリソース的には膠着してしまう) 技術面でのスケーリング可能なラインとの平衡点を見積もる必要がある.

バイクで出かけてたら中原街道のど真ん中でいきなりパンク、汗だくになって1時間かけて押して帰る事に、マジ死んだ.

その後少々あってダブルコンボorz

---------------

VC# 2005 Expressを入れてみる (今まではテキストエディタ+コマンドライン) 実際はVS2005も持っているのだが、C++周りでVS6の関連付けなどがいじられるのが嫌だったので (VC#もその保証は無いので半分賭けだったが、ただ一応VSは全バージョン共存はできる) 期待通りVS6設定は殆ど上書きされず、.NET SDKなども問題なし、なお妙な登録無しでDLできるのはISOイメージ版のみの模様 :-<

一部で言われているもっさりというのが前々から気になっていたのでちょっと凝ったモノで試してみようという事で簡単なエクスプローラのようなものを作ってみる、と言っても単にフォルダをリストとツリーで同期して表示するだけのもの、DLしてIDEの使い方を覚えながらで大体5時間でここまで↓出来た.

ちなみに実行形式やソースはこんな具合 (動作には.NET Framework 2.0が必要)

、、、何気にムチャクチャGUI周りの開発効率良いな、これ(大汗). 扱いやすさは正にBCBのバージョンアップ版といった印象、C++ & APIだと(自分の場合)ここまでで2〜3日はかかりそう (お前がヘタレなのだというツッコミは無しの方向で(^^;

気にしていたモッサリ具合もこの程度のGUIなら殆ど影響していない模様で比較的軽快、確かにGDI+は対話的なアプリやゲーム用としてはやたら重いが、先日の画像拡大・縮小のエンジンでも純粋アルゴリズムの部分はそんなに重くない (但しメモリ的には即時解放されないのが不安定なのでメモリクリティカルなものには向かない、また1プロセスがメモリを比較的食うので多重起動はある程度対策要) 印象、このエクスプローラや先日書いた画像Viewer程度なら何の問題もなさげ (これはちょっと事情があってここでは公開できない) 下手な作り方をする上記程度のアプリでもとやたら重くなるのは C++ & APIでも同じであると考えるとやはり悪くない.

配布やサポートに確かに不安はあるが、反面ビジネス上ローコストである程度オペレーションの付加的価値(※2)を提供できる(※1)という事を考えると、選択肢として考えてみても良いのかなぁとも悩んでみたり、うーん :-<

※1) 実際には確かにベースを用意したりリソースを管理するプログラマの負担は大きく軽減されるものの、内部遷移の処理に要する粒度は通常のAPIプログラムと似たり寄ったりなので、その辺の鳥瞰図を持てないと容易にスパゲッティになる & 細かい所を処理するのにやっぱりWinAPIの知識が必要 (例えば上記のエクスプローラではシェルのアイコン処理&イメージリストの扱いなど) という事で言うと決してバカチョンで底上げというワケにもいかないかもしれないが.

※2) ある程度の規模でワークフローを提供できない限りGUIは所詮周辺でコアにはならないけどね ;-)

TANEさんとこの日記で書かれているwglSwapIntervalEXT (OpenGLでのSwap時Vsync待ち) が見えない件、こちらで試してみた所でもGLコンテキストが取得されていない状態ではNULLが返ってきてる模様、Extなのでグラフィックカードとドライバによってサポートされているかどうかまちまちな話ですが、自分の環境では一応GLコンテキスト作成時は見えているカンジ.

用途がプロッタなので余り確認はしてないのですが、引数 (Swap前に待つフレーム数) に20とか大きな値を入れると表示が重くなる事から多分動いているんじゃないかと考えていたり(^^;;

自分の使っているOpenGLコンテキスト管理のコアはこんな具合 一応FSAAとかも.

---------------

本日のチョンボ

2時間かけてC#で画像の拡大縮小ライブラリ (バイリニア+面積加算) を書いた後でGDI+ならInterpolationModeで指定すれば標準機能でちゃんとした拡縮をやってくれる事に気付いた、間抜け orz

---------------

しかしC#で実際アプリを書く場合、ある程度内部遷移が増えてくると、記述自体はC++と大して変わらないかもしれない、C++で書く場合所有権を明確にする設計でデストラクタにメモリ・リソースの解放を委譲してしまうのでそんなに頻繁に解放コードを書くワケでは無いのと、C#でもメモリを効率的に使うにはDisposeを明示的に呼ぶ必要がある.

とは言えC#の方がクラス設計時に「閉じ」の部分を意識しなくても良い為、考える内容は少ない (うっかりするとNativeリソースの解放を忘れたりDisposeを忘れてメモリが押してしまうが) またC++の場合クラスは全て自分で用意する (MFCとか使う方法もあるが) 必要があるので若干難度があるが、C#の場合は予め優秀なプログラマが作ったクラスライブラリが用意されているので敷居が低いという部分もメリットだろう.

逆にデメリットはアプリの細かい部分の動きを作ろうとした場合にクラスライブラリに機能が用意されておらず、DLLを使うと(DLLがC環境を想定している為)C++程の小回りが効かない事、例えばプロセス間通信で標準が.NET Remote(TCPポート1つ占有する)でMailSlotが無かったり、WM_COPYDATAを扱う場合など自前でコードを書かねばならなかったりみたいな部分があり、結構ソース中にMarshal.〜が大量発生している.

またクラスライブラリの表記が冗長なのでソースコードが横に長くなるとか、定義済みシンボル(enum)の名前のタイプ量が実質2倍程度だとか(MB_OKとMessageBoxButtons.OKとか)、public static extern void〜って人を舐めとんのか、みたいな冗長な表記なんかも個人的にはマイナス (この辺は明らかに個人的趣向)

とは言えGUIのでっち上げ効率はBCBと同程度ではあるし、階層化したイベントも1つのクラスに集約し易く、開発効率の底上げには良いと思う、VB6程周辺が腐った設計では無いし、配布がしっかりした環境での内部ツール作成・イントラ向けなんかでは悪くないのかも、サーバ系は公開サーバにWindows使うのはそも無茶なのでやっぱインターナル向けな気がする、逆に最大のネックはやはり配布の問題 + 次世代ではXPより前は切り捨て、またそれまでのMSのリリース経緯からバージョン互換のメンテナンスが不安という所 :-<