プロジェクトの開始時に、開発ツールを選択するという質問がしばしば発生します。この質問に対する答えがライブラリやアプリケーションとの互換性の必要性に起因する場合、答えは明らかではありません。
別の記事では、Javaまたはインタープリター言語の選択を検討する必要があります。 C ++やC＃よりも望ましい場合もありますが、この記事ではそのようなケースを取り上げず、C ++とC＃の比較に焦点を当てます。
明確にするために、C ++ではアンマネージコードを意味し、C＃ではマネージコードを意味することを示します。 この記事では、 管理対象と管理 対象外を比較できますが、実用的ではありません。 混合コードは、ある程度興味深いものの、この記事の範囲外に大きく残されます。
いくつかのカテゴリー的な声明をおaびしますが、より正確な思考の伝達にはそれが必要だと思います。 基準ごとに比較し、個人的な実践、基本原則、および既知の使用経験に基づいてそれぞれに結論を示します。 それでは始めましょう。
1.開発スピード
C＃を使用すると、開発を迅速に開始できます。これにより、プロトタイプソリューションをすばやく取得できます。 プロジェクトの初期段階でのC＃の開発速度は、C ++と比較してはるかに高速です。
ただし、プロジェクトインフラストラクチャを作成し、主要なアプローチとライブラリを選択し、ビルドを構成すると、C ++の開発速度とC＃の開発速度はほぼ同じになります。
したがって、低予算の短いプロジェクトでは、C＃が開発速度の点で有利になりますが、長くて比較的高価なプロジェクトでは、この利点は取るに足りません。
2.クロスプラットフォーム
C ++は実際にはクロスプラットフォームですが、いくつかの警告、追加コスト、プラットフォーム間のバイナリ非互換性があります。
実際、C＃は、異なるプラットフォームの下に非公式の.net環境が存在し、プラットフォーム間の潜在的なバイナリ互換性があるにもかかわらず、クロスプラットフォームではないことが判明しました。
C＃はクロスプラットフォームになるように設計されていますが、その開発はこの方向に進んでいません。 そのため、Windowsではかなり完全な.netインフラストラクチャが形成されました。 他のプラットフォームでは、同等のインフラストラクチャは表示されませんでした。
同時に、ほとんどの既存プラットフォームでのC ++開発用にほぼ同等のインフラストラクチャが開発されており、既存のプラットフォーム用にコンパイルまたはコンパイルできるライブラリが多数あります。 そのため、C ++で記述されたさまざまなサイズのクロスプラットフォームアプリケーションとライブラリが非常に多くあり、クロスプラットフォームライブラリとともに、個々のプラットフォームに固有のライブラリがあります。 これらはすべて、さまざまなプラットフォームでアプリケーションを開発するための実用的な平等な機会を提供します。
C＃はWindows以外のプラットフォーム用のアプリケーションを構築するために使用できますが、Windows以外の環境で.netを使用することによって生じる問題は、C＃を選択する利点の多くを無効にします。 したがって、C＃のコードがすでに記述されている場合にのみ、クロスプラットフォームでの使用を推奨することをお勧めします。 将来的には追加のサポートコストが発生することを明確に理解する必要があります。
3.コードのパフォーマンスとリソースの要件
明らかな事実は、 アンマネージコードを最適化する可能性がマネージコードを最適化する可能性よりもはるかに広いことです。 したがって、コードのパフォーマンスのピークは、 アンマネージ実行でのみ達成可能です。 限界では、C ++のほとんどすべてのタスクは、より少ないリソース要件で解決できます。 したがって、大量のデータの処理に関連する重いタスクでは、C ++にはC＃よりも強力な利点があります。
しかし、C ++で間違ったアプローチを選択すると、同じタスクを実行するC＃コードよりも実行速度の遅いコードを作成する可能性があることを理解する価値があります。
主観的な「開発のしやすさ」、「コードの美しさ」、および客観的なパフォーマンスの組み合わせについて話す場合、C＃を使用すると、これらの基準を同時に満たすコードを書く方が簡単です。 ただし、これは生産的なC ++コードが必ずしも怖い、または理解するのが難しいことを意味するのではなく、それを書くだけで上記の基準を同時に満たすために、より「創造的な」アプローチが必要になります。
C ++の利点の基本的な基礎は、プロセッサによって直接実行されるコードを記述できることと、メモリを直接操作する可能性です。 もちろん、自由はあなた自身のために問題を生み出すより多くの機会を与えますが、場合によっては、生産性の上限を克服することができないよりはましです。 そして、この上限は、たとえば、1つの適切なサーバーで十分な問題を解決するために、複数のサーバーからファームを収集する必要があるという事実、またはアプリケーションがタスクに「トップエンド」アイロンを必要とするという事実につながる可能性があります7〜10年前に鉄が放出されれば十分でしょう。
4.ライブラリ
C ++ライブラリとC＃ライブラリの品揃えの違いは、C ++ライブラリの数が多いことです。C++ライブラリには素晴らしい歴史があり、そのために多くの場合クロスプラットフォームであり、多くがオープンソースコードです。 ただし、C ++のすべてのプラス面について、ライブラリは非常に異なっており、多くの場合、古風なアーキテクチャでさえあり、多くの場合オブジェクトではなく、構造的および手続き的なインターフェースを持っています。 これは、多くのC ++ライブラリがCライブラリであるためです。
C ++ライブラリのもう1つの不快な機能は、その基本型の作成と再定義です。 多くのC ++ライブラリには独自のタイプの文字列、コンテナがあり、いくつかの基本的なタイプをオーバーライドします。 これには論理的な説明があります（パフォーマンスの向上、クロスプラットフォームサポート、ライブラリ作成時の適切な型の欠如）が、これらはすべて、コードの使いやすさと美しさを追加するものではありません。 基本的なC ++ライブラリは、標準のC＃ライブラリが提供するほど多くを提供しないため、C ++プロジェクトに適切なライブラリを選択することは、比較的単純なプロジェクトでも必要な作業です。
ただし、すべてがそれほど怖いわけではありません。C++には、多くの「美しい」ライブラリがあります。 そして、基本的なライブラリは常に拡大しています。 問題は、多くの場合、この美しさが必要とする犠牲者だけです。
C＃では、上記の問題ははるかに少ないです。 データベースには膨大な数の.netライブラリと、Windowsの主要な開発タスクのほとんどすべてをカバーする自由にアクセスできるライブラリが多数あります。 多数の標準型が存在するため、基本型がオーバーライドされるライブラリはほとんどなくなります。 また、C＃ライブラリは比較的新しいという事実により、原則として、ライブラリインターフェイスはさまざまな設計パターンによりよく適合し、多くの場合、研究が簡素化されます。
ただし、詳しく調べると、特定のC＃タスク用のライブラリがなくなる可能性が高く、さらに、C＃でこのような問題を解決するのに十分な効率が得られない可能性があり、したがって、そのようなライブラリは今後表示されず、その後、十分に速く動作しません。
C＃ライブラリの2番目の不快な機能は、それらの多くがアンマネージライブラリの単なるラッパーであり、常に型変換のパフォーマンスが低下し、追加のデバッグおよび配布の問題が発生することです。
5.デバッグの利便性
単純に、ウィンドウの下では、C＃がデバッグとそこでの停止に非常に便利であると言うことができます。
ただし、何らかの理由でC＃アセンブリの管理されたコードと共にアンマネージドを使用すると、C ++からの管理されていないコードの通常のデバッグよりもデバッグが複雑になります。
6.言語と構文
一見すると、C ++およびC＃コードの外観は非常に似ています。 ただし、C ++はCとC ++およびC ++ 0xの両方であり、これらすべてを同時に使用できるため（もちろん、コンパイラがサポートしている場合）、C ++コードの多様性はさらに大きくなります。
C＃はC＃のみですが、構文は常に拡張されています。 原則として、C＃コードはC ++コードよりもシンプルで簡潔に見えます（ただし、C＃の最初のバージョンについては必ずしもそうとは言えません）。 C ++とC＃の言語構成は非常に似ていますが、詳細には大きな違いがあります。
データベース、遅延バインディング、およびガベージコレクションに「リフレクション」がないためにC ++を非難できる場合。 そのC＃は、本格的なデストラクタの欠如、本格的なマクロの欠如、継承のやや粗い調整、一定のメソッドとメンバーの欠如、グローバルメソッド（手順）の欠如、テンプレートの非常に限られたサポート、リストが続くために非難される必要があります...ケースC ++、ケースC＃。
C＃構文は、おそらくC ++の簡易バージョンと呼ぶことができるので、C＃は、他の単純化と同様に、プラスとマイナスの両方の効果があります。
より単純な言語で記述されている場合、より複雑なコードは、多くの場合、記述および分析が容易であると言う価値があります。 この位置から、C＃を使用すると、基本的に複雑なコードでミスを犯す可能性が低くなり、同じリソースでクリーンなコードを記述する可能性が高くなります。 これは非常に複雑な解決には役立ちますが、パフォーマンスタスクを要求することはありません。 ただし、これにより、C＃の「シンセティックス」の量が増えると、「外観」によるコードパフォーマンスの評価が小さくなります。
7.サポートの費用
アプリケーションサポートでは、C ++とC＃の間に大きな違いはありません。 C＃で記述されたアプリケーションのバグの中には、.netツールでは修正できないものもあり、必要に応じて修正してサポートのコストを大幅に増やすことができることを理解する価値があります。 ただし、リファクタリングについて話すと、C＃で記述されたアプリケーションの方がリファクタリングが少し安くなることがよくあります。
8.リスク
おそらく、C＃を使用する主なリスクは、Microsoftとの強い結びつきです。 もちろん、マイクロソフトは近い将来どこかで消滅することはないでしょうが、マイクロソフトは利益を上げることを目標とする営利団体であり、利益のためには製品を販売する必要があることを理解する必要があります。 したがって、C＃と.netの開発を拡大して、新しいMicrosoft製品の販売につなげることは、Microsoftの利益になります。 したがって、開発の利益がMicrosoftの利益と一致しない場合、遅かれ早かれこれが問題につながる可能性があります。
C ++の使用にはリスクもありますが、これらは他のリスクです。 主に、ライブラリのバイナリ互換性に関連する問題を呼び出します。 ライブラリがソースにない場合、互換性があることが重要です。 たとえば、ライブラリの新しいバージョンを再構築または取得する場合にのみ、別のランタイムへの切り替えが可能になりますが、1つのプロセスでの複数のランタイムの作業は相互作用の問題につながる可能性があります。 これはすべて、プロジェクトの開発コストを大幅に増加させる可能性があります。
開発リスクに加えて、低品質のコードのリスクもあります。 C＃は開発者にあまり要求されないため、C＃に表示される低品質のコードの可能性は、C ++よりも平均的に高くなります。 このようなコードが大量にあるため、アプリケーションに深刻な問題が発生する可能性があります。
C ++の場合、低品質のコードを使用した状況は多少改善されます。 悪いコードが生き残る可能性は低いですが、もちろん、悪いC ++コードの万能薬はそうではありません。
9.アプリケーションの自給自足
C ++もC＃も、アプリケーションの完全な自給自足をしていません。 何らかの方法でC ++の場合、ランタイムが必要ですが、C＃.netフレームワークの場合です。
ただし、C ++ランタイムは、他のライブラリと同様に、実行可能モジュールに静的にリンクできるため、実行可能モジュールには作業に必要なすべてのものを含めることができ、そのため、C＃の場合、それは自給自足になります実行不可能という意味です。
10.組み立ての便利さ
C ++プロジェクトのビルドは、C＃プロジェクトのビルドよりもはるかに複雑です。 ただし、非常に複雑であると柔軟性が増すため、遅かれ早かれ便利になります。 ここまでの真実はあなたの時間のコストを増やすだけです。
11.見通し
見通しについての推論は常に憶測です。 今日、C ++とC＃の両方が積極的に開発されています（ただし、C ++はそれほど前ではなく活発に開発を始めましたが）。
プロセッサパフォーマンスの成長率（少なくともコアあたり）が著しく低下し、近い将来に大幅な増加が見られる可能性は低いという事実に驚かされます。 I / Oパフォーマンスについても同じことが言えると思います。
これはすべて、ほとんどの場合、ソフトウェア製品の最適化と並列コンピューティングの要求を作成します。 私は、C＃がこれらのすべての要求を満たすことができるかどうかについて懐疑的な見方をしています。
結論
「C ++またはC＃を次のプロジェクトに使用すべきか？」という質問に普遍的な答えがあるとは言えませんが、アクティビティのさまざまな期間で、選択した質問に対して異なる答えをすることができます。以前は、C ++を優先選択とは考えていませんでしたが、今ではより多くのケースでそれを使用する傾向があります。 ただし、Windowsでのラピッドプロトタイピングでは、C＃がC ++の推奨ソリューションとなるでしょう。