クロスプラットフォームのC++ツールチェーン

Question

私はC++での経験が限られているダイハードの.NET開発者です。私は実際に幸せに解釈される言語（およびスクリプト言語）がクロスプラットフォームで動作する方法に精通していますが、C++についてはどうでしょうか？

私は、GCC/GPPと他のコンパイラが正しいコンパイラフラグを使ってマルチプラットフォームで動作することを認識していますが、コンパイラ間でSTLが正規化されていることを理解しています。オーディオイン/アウト、高精度タイマーが必要です。マルチスレッドが必要です。私はこれらのことのどれもがSTLでサポートされているとは思わないので、いくつかのタイプのクロスプラットフォームライブラリが必要でしょうか？どちらを使うべきですか？

私は、最新のMacとWindowsプラットフォームをサポートすることを目指しています。これは共有フレームワーク/ SDKであり、UIはありません。 Objective-C/Cocoaや.NET/WPF（いずれも優れたネイティブUIサポートを備えています）などのネイティブ言語でUIを作成する予定です。

私のツールチェーンはどのように見えますか？私はGCC/GPPまたはMinGWを使用すべきですか？クロスプラットフォームで機能する他の「ライブラリ」をどのように統合する必要がありますか？私はMac互換のバイナリとWindows互換のバイナリ（32ビットと64ビット）をビルドできるようにビルド環境を「うまく動作する」ようにセットアップしたいと思います。どうやってやるの？

この時点で、私はこのC++マルチプラットフォームフレームワークsdk/api thingyと相互運用できるように、各プラットフォームのコードを記述します。ウィンドウズでは、これは管理されたDLLのように見えますが、それは正しいのでしょうか？ Macでこれをどうやってやろうと思っていますか？

提案やおすすめはありますか？提案のため

おかげで、 ブレット

Answer 1

1）ここでの本当の目標は、移植性の高いC++を書くことです。特定のコンパイラを使用するのではなく、言語の使用をきれいに保つことで移植性が得られます。

2）オーディオi/oのように、プラットフォームに依存しているものがあります。ただし、特定のモジュール内のプラットフォームの依存関係を完全に分離し、各プラットフォームの一連のプラットフォームサポートファイルを条件付きでコンパイルできます。

3）マルチスレッドのようなものは、標準ライブラリを使用してプラットフォームに依存しない方法で実行できます。

Answer 2

は主観的な領土に入るが、大きなでの作業に使用される現像のために、やる-それを-すべての私たちは.NETで見つけたもののようなフレームワークのようなものを、QTはおそらくあなたのだろう最高のクロスプラットフォームのC + +のアナロジー（私はそれの巨大なファンではないが）。そこにスレッド、XML I/O、ローカリゼーション、ソケット、高精度タイマー、GUI構築ブロックなどがあります。

[...]私はマルチスレッド化を行う必要があります。私はほんの少しの事[...]

をSTLでサポートされている これらのもののいずれかを考えていませんが、STLは、集約コンテナおよびC++標準ライブラリの一般的なアルゴリズムの説明に限定されています。これは同義語ではありませんが、C++ 11では標準ライブラリに並行処理サポートの仕様があります。しかし、普及しているコンパイラはまだそれを完全にサポートするのが遅いです。当面はスレッドを必要とする場合は、また、非常にクロスプラットフォームのライブラリであるhttp://www.boost.orgが必要です。

さまざまな環境（.NET、Cocoaなど）にうまくプラグインできるAPIを構築するためには、最も優れたクロスプラットフォームのオプションは、実際にはC APIを公開することですC++）。これは最小限の頭痛をこの方法で引き起こします（名前のマングリング、複雑な、ユーザー定義のC++型などとの相互作用を試みることに問題はありません）。

グランドライブラリを開発しようとする前に、.NETおよびCocoaアプリケーション（例：C++モジュールをobjective-Cで使用する）を拡張する方法として、C++でDLL /共有ライブラリを構築することをお勧めします。

Answer 3

標準ライブラリのタイミングは、<chrono>で、Macではナノ秒の解像度です。残念ながら、VS11 Betaの時点ではWindows上ではわずか1ミリ秒の解像度しか得られません。私はあまりにも多くの遅れなくそれを修正することを望んでいます。