場合によっては,Unicodeの弊害を盾に最後は「VBでは不可能なUI,あるいはアーキテクチャ」でなしくずし的に目的を達成はじめに現在私がお世話になっています部署では,VBによるコーディングが幅を利かせております。この事自体は構わないのですが,特に近年では,VBによる機能的な制限が非常に緩和されてきたためもあり,以前にも増して「とにかくVBで作る」という風潮にあります。これが工数削減に貢献していればともかく,実際には「VBを使っているが故に」工数が増大している部分が少なからずあります。(例えば,APIを直接呼び出す部分)それにも増して,特にこのところ「VCを使えない人かいるから,VBでやる」というのが多くなってきているように感じており,この点において非常に危機感を持っております。Windowsでの開発だけなら良いですが,将来的にサーバーサイドがLinuxになったりすると,私の部門で開発をする場合に非常に困った事態になってしまいます。Spread-OCXの代替品を見つける私の部署では,表形式のコントロールに,文化オリエントさんの「Spread-OCX」をよく使用しているのですが,とりあえず現時点で(個人的に)一番ネックとなっているのが,このコントロールの存在です。このコントロールは,VB以外のプラットフォームでの動作保証をしていないので,このコントロールの存在意義を薄めることが第一です。近年のUI上の要求で,Spread-OCXの機能では(かなりのコードを書かなければ)実現できないような仕様も増えてきておりますので,Spread-OCXより高機能のグリッド表示コントロールがあり,VCでも使用することが可能であれば,VBで作る根拠の一つが無くなります。何か言われた時に,「それはSpread-OCXではできませんが,こっちのコントロールだとできるんで,こっちに変えましょう。なんかは,データバインド・表示機能共にSpread-OCXよりは高いと思いますが,現実問題としてはPGの慣れが必要になる事でしょうか。安定性については,いくつか採用事例があるようですので,そんなに心配はしていませんが。あとは,カスタマイズの面からすれば,ソースコードが公開されている,HyperGear/Gridはかなり有効でしょう。餌食にするプロジェクトを選定する前述の通り,VCあるいはC言語のレベル時点からのスキルを持つ者が少ない状況では,VCでコンパイルが通るような基礎知識を付けるまでに,かなりの総工数がかかります。理想を言えば,開発量の小さいプロジェクトでかつスケジュールに余裕のあるプロジェクトを餌食にする方が,会社にとってのダメージが小さいのでよいのですが,いままでの仕事の振られ方からして,このような状況は見込み薄です。やるなら,一番リスクの少ない状況下で決行したいと思うのですが...。VBでコーディングレスでできるUIに限定して貰うとりあえず,少しでも怪しいようなUI仕様が出てきた場合には,「これはVBでは無理ですね」といって,VCでの開発に持って行くように心がけます。あとは,事前に,まず出てくるだろうという要求に対して,「こうこうこういう要求が出てくるとVBではできないんで,今のうちからVCでやっとく方が早いんですが,そんなことはないですよね?とか何とか言って,設計側に圧力をかけるのも手です。何か変更を要求された場合は,「だから言ったじゃないですかぁ!最初からVCでやってたらすぐに対応できるのに...ブツブツ」とやるわけですな。敵(VB)を知り,己(VC)を知るVCが,VBに比べて劣っているところには,大きく次の3点だと思います。「とりあえず作る」というのがVCではやりにくい。しても「最終製品ですらとりあえずのもの」的な私の部署で開発するシステムの場合は,とりあえず作る必要に迫られる場合が非常に多く,そのため,開発言語としてVCを選定しにくいということが言えるかと思います。バグを作り込んでしまっている場合,「落ちる」バグや再現性のないバグを作りやすい。VBでは,「落ちる」ようなエラーを出すのは,APIを直接呼び出す場合以外は,けっこう難しいのですが,VCだと,ちょっとでも(特にポインタ操作を)間違うと,すぐに「落ちて」しまい,再実行が必要になります。これは,MTの効率が(VBと比較して)悪いと言うことです。これとは別に,VBでは変数は必ず初期化されますが,VCではクラス以外の変数(クラスについても,明示的に初期化処理を記述しなければ)は初期化されないため,これが不安定なバグの温床になる場合が多いです。バグの修正を,テスト実行中にできない。これも上記と同様,MTの効率の悪化につながります。逆に,VCがVBと比較して勝っているところは,次の5点だと思います。重要な点(良いか悪いかは別にしてですが...)です。Cでできなければ,VBでは(理論的に)絶対できません。Cでできなければ,開発プラットフォーム自体を変更するしかありません。実際問題では,開発工数上VBでしかできない場合があり得ますが。開発者の方からすると,「どんな複雑な要求のコントロールでも作れてしまう」ということになり,仕様拡散を防ぐ根拠の一つが無くなるので困るかもしれません。ランタイムライブラリへの依存が少ない。VBの場合,開発環境がバージョンアップした場合,一部のみを新しい環境で開発するのは,推奨されない場合が多いです。VCでの開発の場合には,必要なら,ランタイムライブラリを0にする事も可能です。これは,既存の旧開発環境で作成したモジュールに,新しい開発環境で構築したモジュールを混在させて使う事が可能と言うことです。これにより,新しい開発環境の機能を使えば開発効率が改善できる場合でも,既存のモジュールとのしがらみで古い開発環境を使うことによって効率を向上させられないという事態を回避する事が可能になります。複数モジュールのリンクが簡単。関数レベルで複数モジュールのリンクを行う限り,VBのように,再コンパイルすると他も全て再コンパイルしなければいけない場合というのは,非常に少ないです。これは,特に後半になるとコンパイルだけで30分とか1時間かかるような場合には,待ち時間が減ります。使われないCOMインターフェースのIDが,不必要に増えない。言ってることが判らない人は,VBでDLLを作ってはいけません。作ったDLLの公開クラスのPublicメンバを変更してはいけません。それであなたの使っているマシンが,いつのまにか遅くなったとしても,それはあなたに原因があります。それはともかく,VCではインターフェンスの変更によって,自動的なバージョン更新が行われないため,上位モジュールの再コンパイルは強制されません。変更があった場合はバージョン更新を手動で行わないといけないというのは,逆にデメリットになりますが。言うまでもないことですが,高速の処理はパフォーマンスチューニングの必要性を減少させます。複雑な文字列処理がある場合には,ポインタでの操作とUnicodeとの文字コード変換等が不要になるため,多くのデータを扱う場合には差が顕著に出てくるかと思います。COMの教育とC言語教育との取引VBの場合,自モジュール以外との通信は,基本的にCOMベースを強制されます。従って,フロントエンドだけならともかく,大規模システムをVBでやる場合,基本的にはCOMの概要を知っておく必要があると私は考えています。別の所でも述べていますが,(設計はともかく)いやでもオブジェクト指向での実装を要求されることになります。計算主体・ファイル操作主体の場合であってもです。Basicマガジンをご覧になってください。COM関連の記事が,紙面のどれだけに充てられているでしょうか?一方,VCでやる場合には,UI部分はMFCやATLを使うことが現実的とはいえ,必ずしもオブジェクト指向でやる必要はありません。計算主体の処理ではなおさらそうです。このオブジェクト指向での開発能力を要求しないという点は,VCを使うことのアドバンテージになります。この点を引き合いに出して,「COMの勉強とC言語の勉強とどちらを選択させますか?」と要求してみるのも手かな?と思ってます。場合によっては,Unicodeの弊害を盾にUnicodeでは,シフトJISコードでは区別されている似たような字(特にマイナーな旧字や異体字)は,同じ文字コードにされています。これはUnicodeとシフトJISとの関係は,1対1ではなくN対1ということです。従って,シフトJIS->Unicode->シフトJISという変換を行うと,変換前後で文字が化ける事があり得ます。具体的な文字を挙げられなくて申し訳ないですが,このレベルまでの字体の厳密さが必要なシステムでは,Unicode処理を避ける必要があります。ところがVBでは,常に処理をUnicodeで行います。従って,このような文字化けが発生すると困るようであれば,VBは言語仕様上使えません。OLEしかり)使えないということになりますし,JAVAも使えなくなります。ファイルシステム内の文字(VFATのロングネーム部分とNTFS)もUnicodeですので,名前を直接ファイル名などにする事もできなくなります。この理由を盾にする場合は,これらのことをおくびにも出さないようにする必要があるでしょう。良いのは,MDI親ウインドウがEXE,MDI子ウインドウがDLLとか,ドッキングウインドウだらけといったような構成で,へろっと決めてしまうことです。これはVBでは絶対できませんので,全UIの設計し直しか,泣く泣く(笑)VCで作るかの選択に持って行くようにしむけます。あと過去の実績としては,プログレスバーの経過表示があります。これは,モーダルダイアログの表示中に,モードレスダイアログを表示する処理を必要としますので,少なくともライブラリ化する場合はVCで作らざるを得ません。あといままでしっかりやっていなかった部分では,マウスカーソル形状の変更(特に砂時計マーク)があります。VBでのマウスカーソルの制御は,自モジュールが持っていないフォームの上にマウスカーソルがある場合には制御できません。従ってDLLからマウスカーソルを制御しても,実用上はほとんど無駄です。このような仕様をしっかり入れておいて,何か言われたら「それは,VBでは言語仕様上できません」といって,VB化を防ぎます。他にも,VB一色の開発からの脱却のため,あらゆる方策を求めております。有効な方策がございましたら,こちらまで。