5

私は一連のアプリケーションを更新する任務を負っています。これらは基本的にネットワーク統計を監視して返すだけの、パフォーマンスが重要な VB.NET アプリです。要件は 3 つだけです。C# に変換すること、高速にすること、安定させることです。

1 つの注意点は、.NET プラットフォームから Linuxに「すぐに」移行する「可能性がある」ことです。

将来的にはこれらのアプリの保守を担当するので、これを正しく行いたいと思います。私はこれらのアプリを MVP パターンに従ってリファクタリングすることに決めました。これにより、この悪い子の地獄を適切に単体テストできるようになります。しかし、MVP を使用していたので、GUI は .NET フォームや Qt などで行う一方で、ネイティブ C/C++ コードで計算コストの高い作業を行うこともできると考えていました。

質問:

  1. Winforms で GUI を実行することは理にかなっていますが、ネイティブで管理されていない C/C++ で高価なものを実行するのは理にかなっていますか?

  2. 上記のシナリオに適した優れたクロスプラットフォーム ウィンドウ キットの推奨事項はありますか?

4

12 に答える 12

5

1) 時期尚早の最適化は悪です。「高価なもの」を C# で実装し、リファクタリングが必要かどうかを確認します。または、少なくともこれを判断できるテストを設定します。

2) ヨッチ。クロスプラットフォーム UI。私は「かもしれない」ものに我慢しません。イタチを釘付けにします。何を設計しているのかを知らずに、どのように設計上の決定を下すことができるでしょうか? 純粋な .NET 実装を使用する場合、Mono で動作するように (少なくとも) リファクタリングする必要がある場合、彼らは文句を言いますか? Java で作成した場合、見た目がひどく醜く、.jar ファイルの中から .exe ファイルが見つからないとユーザーが不満を言うことに、彼らは腹を立てますか?

于 2008-08-13T14:19:25.633 に答える
5

まず、 VB.NET から C# へのコンバーターをいくつか試してみました。基本的に構文を移植しているので、必要がなければ手動で移植する理由はありません。確かに、コンバーターから出力されたものをクリーンアップする必要があるかもしれませんが、それは手動で変換するよりもはるかに優れています。

さて、あなたの質問について：

1) winforms で GUI を実行するのは理にかなっていますが、ネイティブで管理されていない C/C++ で高価なものを実行するのは理にかなっていますか?

まだ。変換が完了するまで待ってから、実際に時間を費やしている場所を見つけてください。必要であることがわかるまで、C/C++ と C# を混在させることに飛びつく理由はありません。安全でない C# にドロップするだけで十分であることがわかる場合があります。それさえも不要かもしれません。アルゴリズムを最適化する必要があるだけかもしれません。ボトルネックが何かを見つけて、それを修正する方法を決定します。

2) 上記のシナリオに適したクロスプラットフォーム ウィンドウ キットの推奨事項はありますか?

私は確かにモノを探しています。C# を使用している場合は、これが実際にできる最善の方法です。Linuxに移行する場合は、モノラルまたは別の言語での別の書き直しです。

于 2008-08-13T19:47:04.350 に答える
3

1) 必ずしもそうではありません。パフォーマンスへの影響に関係なく、バックエンド コードを C++ で記述することはおそらく価値があると言う方が正しいと思います。プラットフォームの切り替えで上層部を拘束することはできませんが、その不測の事態に備えることは賢明です。今すぐ切り替えないと決めたとしても、6 か月後に切り替えないと決めているわけではありません。C++ でロジックを記述することは、より困難ではあるものの可能性があることを知っていれば、後の作業が大幅に楽になる可能性があります。

2) そうでもない。wxWindows や GTK# のような「解決策」はありますが、多くの場合、バグがあったり、適切に動作させるのが困難であったり、プラットフォームによって重要なものが欠けていたりします。また、通常、最も共通点の少ない UI に固定されます (つまり、一般的なコントロールは問題なく動作しますが、それを使用して何か興味深いこと (たとえば、WPF) を行うことを忘れることができます)。UI は簡単に記述できるので、ロジックを移植可能なものに記述すれば、いくつかのプラットフォーム固有の UI を組み合わせるのは簡単なことだと思います。

于 2008-08-13T14:28:51.760 に答える
2

最初の質問については、どのような種類のパフォーマンスを得る必要があるかによって異なる可能性が高いため、それが理にかなっているかどうかを判断するのは非常に困難です. 私は個人的に、WinForms を使用して適切に設計された GUI の GUI が原因でシステム全体の速度が低下するのを見たことがないので、なぜそれが問題を引き起こすのかわかりません。 .

2 番目の質問についてですが、ある時点で別のプラットフォームに移行する予定がある場合は、Mono によって実装されているライブラリを確認したいと考えています ( http://www.mono-project.com/Main_Page ) 。 、これは WinForms と GTK# をサポートするため、クロスプラットフォーム ウィンドウに関するニーズのほとんどをカバーするはずです。

于 2008-08-13T14:24:12.287 に答える
2

いいえ、C/C++ で「高価なもの」を実行しても意味がありません。C# と比較した場合、潜在的な (そしてほとんどの場合マイナーな) パフォーマンスの向上が、生産性を上回ることは決してありません。本当。近くにもありません。

これ (およびその中で参照されているすべての投稿) を読んでください: http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

于 2008-08-13T14:27:41.997 に答える
2

Monoの使用を検討することをお勧めします。これは、Linux、Mac、Solaris、Windows などの多くのプラットフォームで動作する .NET のオープン ソース バージョンです。

次に、高価なものを C/C++ でコーディングします。これは、 C/C++ と C# のパフォーマンスの違いを説明する非常に優れた記事です。

于 2008-08-13T14:34:47.740 に答える
1

繰り返しますが、強調させてください。C++ のものは非常に高価です。私が上で述べたことをするのは理にかなっていますか？(重労働の C++ を隠している .NET フォーム)

前述のように、個人的には、VB.NET と C# の両方で記述されたアプリケーションで WinForms が原因でシステム全体の速度が低下していることに気付いていません。ただし、アプリケーションが本当にパフォーマンスを重視する場合、すべてを C# で記述した場合、CIL ( http://www.cl.cam.ac.uk/research/srg/han /hprls/orangepath/timestable-demo/ )。そのため、C# などの言語で GUI を作成すると、開発のその部分が少し簡単になり、コードの重要な部分に取り組む時間が増えます。ここでの唯一のキャッチ 22 は、C# コードから C/C++ コードへの呼び出しによる速度低下に気付く場合があります。ただし、これはおそらく非常にありそうにありません。

于 2008-08-13T19:13:50.580 に答える
1

1) winforms で GUI を実行するのは理にかなっていますが、ネイティブで管理されていない C/C++ で高価なものを実行するのは理にかなっていますか?

ほとんどの場合、そうではありません。他の多くのネイティブ C dll などと通信している場合を除き、C# は C++ よりも 5% 遅くて 5%速い可能性があります (std::string を使用している場合は、本当に致命的です)。

2) 上記のシナリオに適したクロスプラットフォーム ウィンドウ キットの推奨事項はありますか?

ボタン付きの単純なフォームであれば、mono は変更せずに実行できる可能性があります。最近では、.NET WinForms のサポートがかなり充実しています。しかし、それはお尻が醜いです:-)

于 2008-08-13T20:34:21.353 に答える
0

c / c ++のものは良いアイデアになるかもしれませんが、今はYAGNIです。Linuxのものと同じです。それを無視してください、あなたはそれを必要とするまでそれを必要としないでしょう。シンプルにしてください。あなたが言うように、ユニットテストはそれから地獄をテストします。コードを機能させ、そこから設計を進化させます。

于 2008-10-01T21:23:35.703 に答える
0

gtk-sharpは非常に優れたクロスプラットフォーム ツールキットです。

Gtk# は、モノおよび .Net 用のグラフィカル ユーザー インターフェイス ツールキットです。このプロジェクトは gtk+ ツールキットとさまざまな GNOME ライブラリをバインドし、Mono および .Net 開発フレームワークを使用した完全にネイティブなグラフィカル Gnome アプリケーション開発を可能にします。

于 2008-09-17T14:41:08.820 に答える
0

問題を誤解しているかもしれませんが、ネットワーク監視システムである場合、「専用」の Windows サービスとして記述されていないのはなぜですか?

VB.NET は C# よりも遅くはないはずです。生成された IL コードに大きな違いがあるかどうかは 100% 確実ではありませんが、私が考えることができる唯一の利点 (および C# で書き直す正当な理由) は (C# の方が構文が優れていて、その他の利点があることを除いて) ) は安全でないコード ブロックを使用することで、速度が少し向上する可能性があります。

于 2008-08-13T19:32:12.570 に答える
0

組み込みハードウェア (PCMCIA インターフェイス経由) と対話する PC ベースの H/W テスト ツール (明らかに「UI オプション付き」を意味します) を開発するための最良の方法を見つけようとしていたときに、同様のジレンマがありました。

ボトルネックは、テスターが指定した意図した時間から最大 10 ミリ秒の偏差でテストを実行する必要があることでした。

例: テスターが次のテスト シーケンスを作成した場合:

    1. H/W をリモートでアクティブ化します
    。 2. 50ms の遅延を待ちます。
    3. H/W 情報を読み取ります。

ステップ 2 で述べた遅延は 60 ミリ秒を超えてはなりません。


バックエンドとして C++ WIN32 アプリケーションを選択し、UI 開発には VC++ 2005 Winform (.NET プラットフォーム) を選択しました。これら 2 つのインターフェイスの方法に関する詳細情報は、msdn
で入手できます。私は次 のようにシステムを分離しました:
VC++ .NET の場合:

    1. H/W に関する完全な情報を取得し (バックエンド アプリケーションを介して読み取る)、オンデマンドで H/W を制御するための UI。(ボタン、コンボ ボックスなど)
    2. タイム クリティカルなテスト シーケンスを実行するための UI (上記の例で説明)。
    3. これらの情報を収集し、タイム リニア形式でストリーム (ファイル ストリーム) を構築します (つまり、実行する必要があるステップの正確な順序で)。
    4. WIN32 バックエンド アプリケーションによるトリガーおよびハンドシェイク メカニズム (標準入力および標準出力のリダイレクトによる)。共通のリソースはファイル ストリームになります。

C++ WIN32 の場合:

    1. 入力ファイル ストリームの解釈。
    2. H/W との相互作用。
    3. H/W から情報を収集し、その出力ファイル ストリームに入れます。
    4. UI へのテスト完了の表示 (リダイレクトされた標準出力経由)。

完全なシステムが稼働しています。かなり安定しているようです。（上記のタイミングずれなし）。
私たちが使用するテスト PC は、H/W テストのみを目的としていることに注意してください (自動更新、ウイルス スキャンなどはなく、UI のみが実行されていました)。

于 2009-11-09T08:50:29.053 に答える