C#(.NET) 開発で気になった点

メソッド の const 修飾が使えない

id:logion:20061010#p4 に続き、const 厨には辛い世の中になってきました(笑)。

this キーワード

メソッドからメンバを参照する時は this.hoge のように頭に this をつけるのが普通のようです。(付けなくても問題ありませんがウィザードの吐き出したソースのスタイルに合わせておいた方が自分自身の混乱が少ないので…)
そのため C++ で書いてたような m_ のプリフィックスはもういらんはずなんですが、なぜかつけるのをやめられません…。その理由を胸に手を当てて考えてみましたが、どうも付け忘れた時にそれがメンバだったのか一時変数だったのかが、ソースを見ただけでは判断できないから…のようです。

WindowsForms のコントロールの描画が妙に遅い

TabControl にボタンなど10個程度のコントロールを置いて随時切り替える方式で UI を作り込んでいましたが、タブを切り替える時の描画が実にもっさりした印象があります。個々のコントロールを順番に再描画し直しているのが見えており、Label を多用していると目立ちます。特にひどい箇所は編集禁止にした TextBox に置き換える場面もありました。
大きな Panel に画像を描画する時なんかはキビキビ動いてくれるので、GDI+ が特に遅い訳でもないように思います。画面の再描画処理に全然手が入ってないような感じなんですが、改善される予定はないんでしょうか。じきに WPF に移行するから敢えて改善しないとゆー事なんでしょうか…。

Bitmap の SetPixel()/GetPixel() が遅い

ちょっとした画像処理を書くとあまりの遅さに悶絶してしまいました。色々と検索してみると、Bitmap クラス自体がは GDI+ のラッパであり画像領域は Unmanaged な所に確保されているそうです。ピクセル単位で Managed/Unmanaged な世界を行き来するとオーバーヘッドがシャレにならんからでしょうか。C# による画像処理は AForge.NET のソース等を見ていると unsafe ブロックで囲んでポインタを直接いじるのが定石らしいですが、それでも C++ に比べたら遅いとか…。(参考)
個人的に、C# .NET は「Manage された美しい世界であってほしい(笑)」という幻想を勝手に思い描いている自分にとって、そんな高等な技は早過ぎると思ったので、結局フィルタの内部に押し込めて C++ で実装しました。

ユーザーコントロールをビルドしないとアプリ側のデザイナに表示されない

C++Builder の Frame に該当する、カスタム GUI 部品を作るユーザーコントロールですが、Frame とは異なり、別プロジェクトにする事が強制されるようです。しかも、そのコントロールを使うアプリ側のデザイナを開く際、そのコントロールを事前にビルドしておかないとデザイナ自体にエラーが出てしまい、フォーム全体の GUI のデザインがまったくできなくなってしまいます。まあビルドすればいいだけの話ではありますが、結構不便に感じます。なんでこんな仕様にしたんやろ…。