C言語系の将来性と現在の有用性について

質問

いつもお世話になっております。
以前もこちらのカテゴリで似たような質問をさせていただきましたが、違う視点からまた質問させていただきます。
現在社内では、WindowsVista向けアプリケーションの対応として、VisualBasic6.0で作成した多くの資産をVisualBasic.NET2005に移行する作業を行っております。
資産はPCIボードやシリアルポートを使用してリアルタイム制御を行ったり、ウインドウに数値表示するための、ループ構造のロジックが主です。
私としては、VB6資産独特の不具合(応答性の悪さや、C++向け他社製DLLを呼び出した時の原因不明な動き)が頭に引っかかっているので、.NETへ移行するならば、C++へ移行する方が制御には向いているのではないかと考え、暇を見つけてはVCの移行作業を実験的に並行して行っています(VC++.NETはまだ購入していないので、所有しているVC6.0を使用しています)。
C++が制御に向いている、または処理系を変更することでLinux移行も可能である点を踏まえるとC++言語での開発は今後の転換が柔軟に行える要素を持っていると思います。
一方、VB.NETは生産性やデバッグ機能性が非常に高い、また実行速度もかなり改善させれていると言われて、会社の方針はもっぱらVB.NET化で固まってしまっています。
うちのシステムはハードウェアメーカが公開するAPIがCかVBにしか対応できないので、言語的には二者択一になってしまうのですが、使用OSはWindows/Linuxの選択肢は用意されています。
これらを前提として、VB.NETへ移行するメリット/デメリット、またC++言語へ移行するメリット/デメリットにはどんな事があるのでしょうか？
ちなみにVB6.0以前での開発は、MicrosoftCでMS-DOSアプリケーションを作っており、Windowsマシンの普及によってVBへ移行した実績があります。

回答No.4

don_go · ベストアンサー

No.3 捕捉
(1)次期Visual Studio
米Microsoft、次期Visual Studio "Orcas"のベータ1をリリース
ttp://journal.mycom.co.jp/news/2007/04/20/016/

既に次期Visual Studioベータ版が出ているようです。

(2).NET Framework 3.0 環境構築
http://www.microsoft.com/japan/msdn/netframework/downloads/netfx3.aspx

.NET Framework 3.0 ランタイム及びVisual Studio 2005
Extensionsを追加インストールする事により .NET Frame
work3.0での開発が行える様です。
但し、
＞※Visual Studio 2005 Extensions WCF, WPF で提供する
＞機能は、次期 Visual Studio “Orcas” で正式にリリース
＞する予定です。Visual Studio 2005 Extensions WCF, WPF
＞に関しては Visual Studio "Orcas" のプレビュー版として
＞先行リリースされ、正式サポート対象ではありません。
及び、Express Editionで一部制限があります。

訂正
No.3
＞.NET 2000, 2002, 2003, 2005とバージョンアップが
　　↓
＞.NET 2002, 2003, 2005とバージョンアップが

回答No.5

noname#30727

ANo.4です。
>C++用DLLしか用意されていないものをVCのDLLをワンクッション入れてVBで使うシステムがあり、目下この問題がペンディング状態です。これがVB.NETで解消されえるかは微妙な情勢です。

C++用DLLというのは汎用DLLの事でしょうか。
汎用DLLでインターフェイスにマーシャリング可能なデータ構造だけを使用しているなら.NETアプリから直接呼び出せます。DLLを作る側が無茶をしていなければ問題になる事はないのですが、例外はあると思います。
http://msdn2.microsoft.com/ja-jp/library/w4byd5y4(VS.80).aspx
DLLが不具合なく簡単に呼び出せなければ、フレームワークが優れていたとしても、.NETはゴミの山ですから、ここで問題になるならVB.NETは切り捨てるべきしょうね。

お礼

inthefloiさん、度々のご回答ありがとうございます。

不勉強なもので、汎用DLLとその他の違いが分からないのですが、
本体のDLLの引数が構造体渡しであるためにVBからダイレクトに呼べず、一度VCのロジック上で呼び出すDLLを作成し、受け取った構造体のアドレスを更にVBで受け取る、というフローになります。

構造体を含めた引数や戻り値の型はVBと同じ(DWORDです)なので、ひょうっとしたらマーシャリングというのは可能かもしれません。

回答No.3

noname#30727

>C++が制御に向いている、または処理系を変更することでLinux移行も可能である点を踏まえるとC++言語での開発は今後の転換が柔軟に行える要素を持っていると思います。

C/C++が制御に向いているというのは、ネイティブコードである事で、速度が重要な割り込み処理が直接書けたり、マイコンなどではC言語しか用意されていない事が多いというのが理由ではないでしょうか。
そういうドライバレベルの処理がライブラリで用意されているなら、あえてC++にこだわる必要はないと思います。

処理系を変更すればLinuxにも移行できるというのも、実際にはそんなに簡単な話ではありません。WindowsでVBからC++に移行する事と、WindowsからLinuxに移行する事は、どちらも同じくらい大変です。

企業として柔軟性を持っていたいという事はわかります。
短期目標としてVB.NETに移行して足場を固め、長期目標としてマルチプラットフォーム化を考えるというような現実論であれば良いのですが、あまりにもハードルを上げすぎてしまう事は賛成できないです。

お礼

inthefloiさん、とても現実的なご回答、ありがとうございます。

>あまりにもハードルを上げすぎてしまう事は賛成できないです。
->おっしゃる通りです。会社は既にVB.NETで移行作業を行う方針を固めてしまっている、またC++言語の処理系がVB.NETより優れているかどうか証明できない点で、短期的には方針を転換するだけの説得力がありません。

>ドライバレベルの処理がライブラリで用意されているなら、あえてC++にこだわる必要はないと思います。
->先の方々のお礼でお伝えした中で、C++用DLLしか用意されていないものをVCのDLLをワンクッション入れてVBで使うシステムがあり、目下この問題がペンディング状態です。これがVB.NETで解消されえるかは微妙な情勢です。
一部のハードウェアメーカはVB用のドライバが用意されていて、これは問題なく稼動しています。

C++化やLinux化の両方共通ですが、現状は実業務と別に移行作業を行い、その過程でサンプル的に小規模なシステムを一度作成し、プレゼンしたいと考えています。
VB6.0資産を.NETへ移行する作業が滞っているだけに、歯痒いです・・・

回答No.2

don_go

■VB.NETのメリット
　新規作成時の生産性やデバッグ機能性が非常に高い
　(ハードウエアの制御を伴わない場合)
　＃生産性が高いのは.NET Frameworkの枠内での話
　ハードウエア制御を伴う場合には、ハードウエア
メーカの対応次第
　OS・言語がバージョンアップされたら、アップデート
対応のプログラム修正またはリプレース需要が発生して
儲かる

■VB.NETのデメリット
　数年先にどうなるかが不明
　.NET 2000, 2002, 2003, 2005とバージョンアップが
されてきていている
　また.NET 2000でそれまでのVBから多きな仕様変更が
行われたが2005になって若干旧VBに近いものへと仕様が
変わるといった揺れ戻しともいうべき状況もあり、言語
仕様が安定していません
　さらに現行の VB2005 では.NET Framework 2.0対応と
なっていますが、既にVistaでは.NET Franework 3.0が
出ているので今までの経緯からして.NET Framework 3.0
対応(及び64ビットCPU対応)のバージョンが近年中(2007
または2008)に出てくると予想されます
＃再度の移行作業発生(!?)

　製品寿命が長い場合、開発環境をOS、言語共に保持して
おく必要がある
＃環境・バージョンへの依存性が高い為

■C++のメリット
　VC++ 2005ではWindowsネイティブと .NET Framework の
両方に対応が可能
　OS依存のクラスライブラリ等を使用しなければ、OSに
依存しないアプリケーションの作成が可能
　ハードウエア制御が楽にできる。
　Windowsネイティブの場合は、仕様が枯れているので大きな
仕様変更は少ない
　MS以外からもC++が出ているので、移行が可能
　他のOSへの移行も可能

■C++のデメリット
　MSがあまり力を入れていないせいか開発環境が若干不便
　一般に習得が難しいとされる

お礼

don_goさん、ご回答ありがとうございます。
具体的な展望をいただけて参考になりました。
うちの会社は特にユーザでWindowsにこだわる人、更にはWindowsVistaにこだわる人がいないので、常に最新の実行環境を求めていません。
一方、XPからライセンス管理が厳しくなり、仰る通りOS環境と、それが動作するハードを常に保管しておく手間が発生しています。

うちのシステムは、基本構造のループ部分以外はほとんど既存の共通部品を流用するので、C++へ一度移行してしまえば、以後の開発は大きい労力が掛からないのではないかなぁ、と考えています。

回答No.1

MrBan

■VB.NETのデメリット

VB.NET(というか.NET系全般?)から、非.NETのDLLを呼ぶのはちょっと面倒ですが、把握されますか。
# CかVBと書かれている場合、普通VB.NET用ではないと思われます。
# VB.NETはVBというよりは.NETなので、.NET用でないとこうなります。

VB.NETとVB6以前は、似て非なる別言語ですが把握されてますか。
(それゆえにMSも"VB6の延命"をせざるを得なくなったほどです)

.NET frameworkが環境に必要です。1.1,2.0,3.0等のバージョンがありますが、
PCにより、インストールされていない可能性があります。

■VB.NETのメリット

.NET frameworkが提供する便利なクラスライブラリが使えます。
メモリ管理などの点で簡便です。
C#との親和性が高まります。

■C++のデメリット

VB.NETと比べればメモリ管理等が面倒です。

MSがあまり力を入れていないようです。
# 「C++でしかできないこと」もあるので捨てはしないでしょうが、
# やはりできれば.NETに誘導したいのでしょう。

■C++のメリット

Linuxでも使えます。

(恐らくネイティブ同士なので).NETから呼ぶよりはDLLが楽に呼べます。

"作り方次第で.NETより高速な処理が実現可能"です。
(大差ない可能性もありますけど)

.NETに依存しません(MFCは静的リンクなども可能で配布しやすいです)

・VB.NETと異なりC++はISO/IEC標準で、仕様が枯れています。
(MSと心中する可能性が低いです)

# C++/CLIなどという.NET2.0以降用のC++風言語(似て非なる別言語)なんてのもありますね。

お礼

MrBanさん、こんにちは。スレ間違いにも関わらず、親身にご回答ありがとうございます。
逆のご質問については、お伝え不足な部分があったので、補足でお伝えさせてください。
二度手間になってしまいますが、もし余力をお持ちでしたら、どうぞお付き合いください。

補足

>VB.NET(というか.NET系全般?)から、非.NETのDLLを呼ぶのはちょっと面倒ですが、把握されますか。
->現在VB.NET資産は移行開発中で、テスト段階にも至っていません。

メーカ配布のC++言語で作成されたDLLが上手く動作しない件
->このDLLを一度VBで使用できるよう、引数の型をVB用に置換するプログラムを別にDLLとしてVCで作成し、VBアプリケーションからはこのDLLのみを呼ぶ仕組みです。
納入したユーザから、この手法に問題があるのではないか、と指摘を受けた経験があります。

>VB.NETとVB6以前は、似て非なる別言語ですが把握されてますか。
->VB6からVB.NETへの移行が必要である点で言語仕様がかなり違いがある、などのざっとした相違点は知っています。

また、現在並行してVC6で作成中の資産移行作業は、あくまでテンポラリのもので、VCより良い開発環境があればそちらへ更に移行したいと考えています。