私は伝統的にC++コーダーです。過去12か月間、私は多くのC#コーディングを行ってきましたが、C#の実用的なアプローチに驚かされました( "ガベージコレクションを備えたC++"であるかのようにコーディングをやめたとき)。
私たちは最近、いくつかの卒業生を抱えており、そのうちの1人を支援するときに、彼女がC++内で.Netを使用していることに気付きました。理由を尋ねたところ、「マネージャーからC++を使用するように言われた」と述べた。明らかなコミュニケーションの問題はさておき、彼女は.Netを使用していたと思います。
その後、C++を使用してフォームのフロントエンドを駆動する上級開発者による古いプロジェクトに遭遇しました。これは.Netが最初に登場した頃に書かれていたので、.Netで遊ぶのは彼の側の学習課題だったと思います。それは小さなユーティリティアプリにすぎませんでした。
このアプリでいくつかのマイナーな変更を行わなければならなかったので、C++を使用して.Netを駆動すると、両方の世界で最悪の事態が発生するように思えました。管理されたフレームワークを扱っているため、ガベージコレクションやメモリの安全性はありませんが、同様に実際の速度/最適化の機会もありません。
だから私の質問は、人々が大規模なスタンドアロン(つまり、非配管)の本番コードにC++ .Netを使用するかどうか、そして使用する理由は何ですか?私はC++ .Net拡張機能を深く掘り下げたことがないので、私はそれを害するかもしれません。
C++。NET(正確には、C++/CLI)does .NET上で実行される他のすべてと同様に、ガベージコレクションがあります。 C++本体との互換性を維持しながらこれを達成するために、^
構文とgcnew
はガベージコレクションされた(「安全な」)ポインタ用です。
C++/CLIは多くの人に嫌悪されていると考えられており、C#やC++のどちらよりも作業するのはかなり不快であり、どちらよりも複雑です(単にC++自体の複雑さを表にもたらし、作業に必要なものを追加するためです) .NETを組み合わせて)。 C#の学習は、通常、単一の中規模プロジェクトの範囲内でも効果があります。ただし、C#でもネイティブC++でもできないことの1つは、既存のC++を.NETに対してコンパイルし、他の.NETコンポーネントと通信させることです。
そのため、最初からプロジェクトを作成するためにC++/CLIを使用することはあまり意味がありません。これを使用して実行できる.NET関連は、C#でも実行できます。より優れた構文と、rawを公開しないという安全性が追加されています。デフォルトではポインタ。その最も著名な存在理由は、既存のコードベースを.NETに移植することです。 .NETの使用を開始することを決定したが、これまでに作成したすべてのソフトウェアを書き直すことを望まない(またはリソースと時間の制約のためにできない)企業は、C++/CLIを使用して、最小限の変更のみで既存のコードベースを使い続けることができます。システムのコンポーネントをC#で1つずつ書き換えます。少なくともそれは理論です。実際にそれが実際に行われるのを見たことがないので、それがどれほどうまく機能するかわかりません。
また、C#自体はネイティブライブラリとインターフェイスできるので、既存のC++コードベースを使用する必要がある場合でも、必ずしも.NETに対して再コンパイルする必要はありません。多くの場合、COMまたはP/Invokeを介してそれらとインターフェイスするのが優れたソリューションです。 。