現在、ObjectARXなどのライブラリを使用してDLLを構築する複雑なVC++ソフトウェアアプリケーションがあります。 C#には、現在のアプリケーションをより効率よく構築するために使用できる、コレクション、ジェネリックス、その他のライブラリなど、多くの機能があると思います。
私はそれについて考えていましたが、上司や同僚にそれをどのように提示するかわかりません。
私が正しい方向に考え、チームにそれをもたらすためのポイントを強調するのを助けるために、私はどんな助けにも感謝します。
私が思ったいくつかの点がありました。
それはあなたが思うほど多くの利益をもたらさないかもしれない非常に危険で費用のかかる考えであることを考慮すべきです。
次のことを考慮してください。
C++は非常に高いレベルで使用できる言語です。つまり、クロスプラットフォーム(VC独自の拡張機能をどの程度使用したかによって異なります)であり、非常に成熟したツールが多数存在します)です。 C++ 11はさらに厄介なユースケースを処理するためにジューシーなビットを追加します。
完全な書き換えを検討している場合は、完全にデバッグされたコードの書き換えが新しい機能を実装しない時期であることを忘れないでください。 C#を使用する明確な利点がない場合、これは時間とお金を費やしています。
チームがC++を知っている場合、C#がもたらす利点にもかかわらず、長い間、C#でのコードの記述は遅くなります。
アプリを移行するには、2つのオプションがあります。最初から再起動する(そして http://joelonsoftware.com/articles/fog0000000069.html を参照、既に投稿されている)か、マッピングレイヤーを維持して新しい機能を追加しますC++およびC#コード。 C#はネイティブコードの呼び出しに関しては非常に優れていますが、それでもかなり複雑なコードを書く必要があります。 P/InvokeまたはC++/CLIのいずれかを使用する場合、どちらも、純粋なC#ソリューションで必要とされるよりもはるかに深いプラットフォームの詳細を知るように強制します。また、マネージコードとネイティブコードの間でデータをマーシャリングするのにかなりの時間を費やすことになります。 COMがより良いオプションかもしれませんが、ATLプログラミングが好きだと思います。
C#の最大の利点は、そのシンプルさとガベージコレクターであり、多くのコーナーケースについて考える必要がありません。つまり、C++に必要なものよりもハードコアではない開発者が開発できるということです。あなたの場合、あなたのチームはすでにC++を知っているので、これらの利点はほとんどありません。 unique_ptr、shared_ptr、RAIIなどを使用すると、C++の危険な部分の多くを管理できます。はい、あなたは足で自分を撃つためのより多くのオプションがありますが、危険な部分を避けます。
完全な書き換えについて話していない場合は、はい、C#でアプリケーションのsome部分を開発することは可能かもしれません。ただし、alwaysは、C++とC#間のマッピングレイヤーのコストに注意してください。 C#パーツをCOMモジュールとしてエクスポートし、C++から呼び出すことをお勧めします。それが本当の利点をもたらすことを確認してください。常に変換する必要がある場合vector<>
からIList<>
そしてC++タイプを常にC#タイプに変換する必要があります。C#の速度上の利点は失われます。 everythingがCLR内に留まることができる場合、C#および.NETへの変換のほとんどを得ることができます。 CLR内にすべてを取り込むことは、複雑なアプリケーションを完全に書き直すことを意味し、それは危険な命題です。
全体として、私はそれをお勧めしません。
本当に悪い決断をたくさんしようとしているようです。
C#の方がC++よりも開発時間が比較的短いことを強調します。
それは聞こえます信じられないほど容疑者。たとえば、チームがC++を知っていても、C#を知らない場合は、確かに正しくありません。
C#には、現在のアプリケーションをより効率よく構築するために使用できる、コレクション、ジェネリックス、その他のライブラリなど、多くの機能があると思います。
C++には間違いなくそれらの機能があり、実際、ジェネリックは他のどの言語よりもC++でより簡単です。どこかでC#の方が優れていると聞いたようですが、何週間もかけてすべてをC#に書き直して、実際にはC++での作業よりもC#での作業に優れているとは言えません。 STLから始めてブースト...
デザインパターンを使用します。これにより、アプリケーションをより適切に維持できます。
あなたはデザインパターンが何であるかわからないようです。
簡単に言うと、伝聞に基づいて健全なエンジニアリングのケースを作ることはできません。あなたは技術的な知識でそれをしなければなりません。
現在、複雑なVC++ソフトウェアアプリケーションがあり、ObjectARXなどのライブラリを使用してDLLを構築しています。 C#には、現在のアプリケーションをより効率よく構築するために使用できる、コレクション、ジェネリックス、その他のライブラリなど、多くの機能があると思います。
(備考。ObjectARXはAutoCADの拡張APIです。したがって、OPは、深いドメインに特化した知識を必要とすることが知られているドメイン固有のアプリケーションについて尋ねています。)
深呼吸して、ソフトウェアの複雑さがドメイン(コンピューター支援設計と計算幾何学)に起因するのか、言語の選択に起因するのかを自問してください。複雑さがドメインに起因する場合、言語を変更しても、仕事が大幅に簡単になるとは限りません。
ばかげた例を使用した適例:Polygon
はIList<Point2>
と同じではありません。繰り返しポイントを確認する方法をIList
で知るにはどうすればよいですか?自己交差するセグメント?コプレーナ2Dポリゴンを3D空間の平面に埋め込む?
場合によっては、一部の言語に構文糖がないために、ドメイン固有のソフトウェア開発が実際に複雑になります。主な例はラムダ関数です。 C++ 11では、これらのエッセンシャル構文シュガーを使用して、コードを簡素化および最新化できます。これが事実である場合、C++コードを最新化することは、C#に移行するよりも良い選択かもしれません。
他の読者への別の見解:ObjectARX for Visual Studioの各リリースは、Visual Studioの特定のバージョンに関連付けられており、後方互換性も前方互換性もありません。 ObjectARX 2013では、VS2010 SP1の使用が必要です。 (したがって、ベンダーがObjectARXの新しいバージョンをリリースし、顧客(OPの雇用者)がそれにアップグレードしない限り、OPはVS2012の使用を簡単に推奨できません。) http://usa.autodesk.com/adsk/servlet/item? id = 12257036&siteID = 123112
さいわい、VS2010 SP1は、C++ 11構文の有用なサブセット(すべてではない)もサポートしています。特に、イテレータのforループは、新しく作成されたコードをいくらか単純化します。ただし、メリットは古いコードの変更を正当化しない場合があります。
私はそれについて考えていましたが、上司や同僚にそれを提示する方法がわかりません。
最善の方法は、上司(理想的にはソフトウェアアーキテクト)に非公式に検討を依頼することです。プラットフォームの選択、移行、プロジェクトの長期的な実行可能性など、あらゆる可能性に目を光らせるのが彼の仕事です。
スーパーバイザーやソフトウェアアーキテクトよりも知識が豊富な場合(これはほとんどあり得ません)、別の仕事を見つけてください。
私が正しい方向に考え、チームにそれをもたらすためにポイントを強調するのを助けるために、私はどんな助けにも感謝します。
私のおすすめ:
ローマは1日で構築されませんでした
架空の再実装の任意の時点で、アプリケーション全体がデモントラブルである必要があります(少なくとも実行可能でテスト可能)。したがって、VC++で記述された部分とC#で記述された部分が含まれます。アプリケーションがまだ問題なく動作していることを示すことができれば(大きなバグ、問題、非効率性はありません)、プロジェクトのC++からC#の未来への「ジャングルパス」が見つかりました。
サンプルワークシート:
もう1つ重要な質問:
これを実行した場合は、ソフトウェアアーキテクトに調査結果を提示します。ソフトウェアアーキテクトは、このジャングルパスの残りのセクションで障害物を特定する責任があります。
C++とC#が相互運用できる方法がわからない場合... ダウン投票の急流があなたの苦労して稼いだ評判ポイントを焼き払う前に、この質問をできるだけ早く閉じることをお勧めします...
一部のアプリケーションはC++で、一部はC#で実行しました。
確かに、C++はC#よりも複雑になる可能性があり、C#にはLINQ、ガベージコレクションなどがあります。ただし、コレクションやジェネリックなどの機能はC++でも利用できます。STL、Boost、C++ 11をご覧ください。
あなたのC++コードを「近代化」することは、私にとってより良い選択のようです。
絶対に必要な場合を除いて、アプリケーション(CLRまたはP/Invoke)でC++とC#の両方を使用することは避けてください。 DLLデバイスのC++で記述されており、アプリケーションはC#で実行されています。マッピングレイヤーが原因で問題が発生します。
100回のうち99回です。コードを最初から書き直すよりも、コードをリファクタリングする方が適切です。
別の言語への再実装については、以下のようにしてください[〜#〜] sure [〜#〜]メリットは、短期および長期の両方のコストとリスクを上回ります。参考までに:アプリケーションのサイズや複雑さが増すにつれて、この決定が理にかなっている可能性は低くなります。