2

ライブラリ Loki と新しい標準 C++11 についていくつか質問があります。

私の最初の質問はLevelMutex、ライブラリの機能についてです。 機能を実装するために、Windows とLinux でLevelMutexを直接使用します。クラスは非常によく設計されていますが、頭の中に疑問が残ります。新しい標準 ( ) に真新しいラッパーができたので、プラットフォームに依存する低レベル オブジェクトをこれに置き換える価値はありますか? そうでない場合、なぜですか？私の要点は、- Loki で多くのコンパイラ チェックを削除できることです。Loki の最新バージョンを維持でき、標準ライブラリで変更が発生した場合、すべての変更が Loki にプッシュされます。Loki の例外を使用できます。CRITICAL_SECTIONpthread_mutex_tstd::mutexstd::mutex

私はそれstd::mutexがプラットフォームミューテックスオブジェクトの単なるラッパーであり、例外もシステム固有のエラーのラッパーであることを知っていますが、それでも...同じ質問が の機能に適用されThreads.hます。

2 番目の質問はSmartPtr、Loki に実装されている についてです。shared_ptr、などがあるという事実を考えると、この実装を使用する価値があると思います unique_ptrか? もしそうなら、なぜですか？そうでない場合は、 LockingPtr 実装を少し書き直して、スレッドセーフな shared_ptr を取得することをお勧めします。

最後の質問はstd::thread、C++11 標準の新しい機能についてです。結合可能なスレッドや取り外し可能なスレッドを作成する機能など、この特定の機能のポリシー クラスを作成することを考えています。のどの部分についてstd::threadポリシーを作成するのが興味深いと思いますか?

回答ありがとうございます！

4

1 に答える 1

3

これは広範でやや主観的なトピックであり、個人的なアドバイスしかできません。一歩下がって全体像を見ることが重要だと思うので、詳細には触れません。

新しい C++11 標準を使用し、他のライブラリを標準ライブラリが提供するものに置き換えることで、いくつかの良い経験をしました。また、「私」とは、私が働いている場所 (従業員が 100.000 人を超える企業の一部門) のコード ベースも意味します。

Loki や Boost などのライブラリは、新境地を開拓し、C++ を前進させるという点で非常に優れた仕事をしてきました。Boost にとって、最終的に標準化される新しいコンポーネントを作成することは、実際には明確な目標でした。

と の標準化されたバージョンはstd::shared_ptr、いくつかの詳細が欠けている可能性がstd::threadありますstd::mutexが、適切に設計され、移植性があり、コンパイラに同梱されている標準ライブラリの一部であるため、非常によくテストされています! これらは、それらを支持する重要なポイントです。また、コードを将来にわたって保証し、保守しやすくするのにも役立ちます。新しい人が飛び込みやすくなります。

したがって、私のアドバイスは次のとおりです。C++ 11 (標準ライブラリを含む) が提供するすべてのものを可能な限り使用してください。必要に応じて Loki、Boost、またはその他のライブラリのみを使用しますが、それらの開発に従うことで心を開いておいてください。

于 2013-09-29T11:49:30.410 に答える