Lokiライブラリは、非常に広く使用されているいくつかの概念 (スマート ポインター、ビジター、ファクトリーなど) を実装しています。関連書籍「Modern C++ Design」がよく取り上げられますが、ライブラリ自体はあまり使われていません。何故ですか?
ほとんどの開発者は Boost を好むようです。特に、Loki のスマート ポインターではなく Boost のスマート ポインターを使用することがよくあるのはなぜですか?
Loki は、研究/概念実証のようなものです。Alexandrescu は新しいアイデアを推し進め、他の人々はそれを現実の世界に採用します。またboost::shared_ptr
、ほぼ文字通りTR1にあります。
Loki's は、いくつかの機能領域 (スマート ポインター、シングルトン、関数オブジェクト、スコープ ガードなどのいくつかの特定のアプリケーションによるテンプレート メタプログラミングのサポート) に触れる優れたライブラリであるという欠点がありますが、boost は通常、各機能領域を徹底的にカバーする多くのライブラリのコレクションです。移植性のためにはるかに高度に調整されています(最初)。
同じ石で 10 羽中 9 羽の鳥を殺すことができる場合、多くの人はブーストから始めて、サードパーティのライブラリでギャップを埋めます。重なるとブーストに対抗するのは非常に難しいです。ブーストの大部分と重複しないため、人々はブーストをダウンロード/インストールして他の機能を取得します。そのため、ブーストが苦手な領域を突き止めない限り、違いがプロジェクトにとって重要である場合、彼らは「解決します」ブースト用もあります。
さらに、Alexandrescu は Loki をブーストに含めようと繰り返し試みましたが、主要なブースト作成者の何人かは協力的ではありませんでした。私の個人的な見解では、彼らはより完全ではあるがユーザーフレンドリーではないMPLがより多くの「市場シェア」を持つことを望んでいるということです。優れたオンライン ドキュメントを備えたライブラリ) を使用すると、これらのライブラリはこれで十分に機能します。
この分析に気分を害したり異議を唱えたりする人がいれば、私は耳を傾けます。
非常にパラメータ化されたコードのもう 1 つの実際的な問題は、さまざまな開発者/チームが独立して作業する大規模なプロジェクトでは、同じテンプレートの微妙に異なるインスタンス化をかなり恣意的に使用することになることが多いことです。これにより、これらのサブシステム間で値を渡すことが難しくなります。受信者は次のことを行う必要がある場合があります。
これはすべて可能ですが、地形をナビゲートするには優れたプログラマーが必要です。
あなたは次のプログラマーが知っているライブラリを使いたいと思っていて、それは将来よくサポートされるだろう - だからあなたはメジャーなライブラリを選ぶ。多くの人が使用する主要なライブラリであるため、デフォルトの選択になります。
私は実際に Loki のやり方を好み、Loki 自身に Decorator パターンを提供しました。これは、私が知る限り、プロジェクトがもはや維持されていないため、トラッカーに置かれています。
すぐに標準になるという理由だけで、boost shared_pointer を使用します。希望どおりに動作するようにカスタマイズできないという事実は嫌いかもしれませんが、それと一緒に暮らす必要があります。
標準ライブラリの使用は、他のプログラマがコードを維持できるようにするために重要です。オープンソースで実験したい場合は、先に進んで Loki を使用してください。誰もあなたを止めていません。
実際、Windows Vista は Loki の機能の一部を使用しています。
彼らは、スマート ポインターとビジターの冗長な実装を使用していないと推測しています。
Boost ライブラリをかなり使用し、Loki を何度も見た者として言えば、最大の問題はドキュメントのまばらさでした。また、Loki は C++ テンプレートの最も複雑なビットを使用します。わくわくするものですが、かなり気が遠くなるようなものでもあります。
私は Loki をちょっとしたツール (基本的にはインタープリター) に一度使用しましたが、実際に気に入りました。私の同僚はライブラリにそれほど熱心ではなかったので、その使用はこの小さなサブプロジェクトに限定されたままでした。