ACE vsブーストvs POCO
私は Boost C++ Libraries をかなり長い間使ってきました。 Boost Asio C++ library ネットワークプログラミングが大好きです。しかし、他の2つのライブラリー [〜＃〜] poco [〜＃〜] と Adaptive Communication Environment（ACE）framework に紹介されました。それぞれの長所と短所を知りたい。
Rdboundが言ったように、Boostには「STLに近い」ステータスがあります。したがって、別のライブラリを必要としない場合、Boostに固執します。ただし、私は [〜＃〜] poco [〜＃〜] を使用します。これは、私の状況にいくつかの利点があるためです。 POCO IMOの良い点：
より良いスレッドライブラリ、特にアクティブメソッドの実装。また、スレッドの優先順位を設定できるという事実も気に入っています。
boost::asioよりも包括的なネットワークライブラリ。ただし、boost::asioも非常に優れたライブラリです。XMLやデータベースインターフェイスなど、Boostにはない機能が含まれています。
Boostよりも1つのライブラリとして統合されています。
クリーンでモダンで理解しやすいC++コードがあります。ほとんどのBoostライブラリよりもはるかに理解しやすいと思います（ただし、テンプレートプログラミングの専門家ではありません:)）。
多くのプラットフォームで使用できます。
POCOの欠点は次のとおりです。
ドキュメントは限られています。これは、ソースが理解しやすいという事実によって多少相殺されます。
たとえば、Boostよりもはるかに小さなコミュニティとユーザーベースを持っています。たとえば、Stack Overflowに質問を投稿した場合、回答が得られる可能性はBoostの場合よりも低くなります。
新しいC++標準とどれだけうまく統合されるかはまだ不明です。 Boostにとって問題にならないことは確かです。
私はACEを使用したことがないため、実際にコメントすることはできません。私が聞いたことから、人々はPOCOがACEよりも現代的で使いやすいと感じています。
Rahulのコメントに対するいくつかの回答：
汎用性と高度性については知りません。 POCOスレッドライブラリには、Boostにはない機能がいくつかあります：
ActiveMethodとActivity、およびThreadPool。 IMO POCOスレッドも使いやすく理解しやすいですが、これは主観的な問題です。POCOネットワークライブラリは、HTTPやSSLなどの高レベルのプロトコルもサポートします（
boost::asioでも可能ですが、わかりませんか？）。けっこうだ。
統合ライブラリには、一貫したコーディング、ドキュメント、および一般的な「ルックアンドフィール」を備えているという利点があります。
クロスプラットフォームであることはPOCOの重要な機能であり、これはBoostに比べて利点ではありません。
繰り返しますが、POCOが必要な機能を提供し、Boostにない場合にのみ、おそらくPOCOを検討する必要があります。
3つすべてを使用したので、ここに0.02ドルを示します。
Doug Schmidtに投票し、彼が行ったすべての仕事を尊重したいのですが、正直なところ、ACEは軽度にバグが多く、使いにくいと感じています。ライブラリには再起動が必要だと思います。これを言うのは難しいですが、TAOを使用する説得力のある理由がない限り、またはUnixバリアントとWindowsの両方でC++を実行する単一のコードベースが必要でない限り、今のところACEを避けます。 TAOは多くの困難な問題に優れていますが、学習曲線は激しく、CORBAには多くの批評家がいる理由があります。どちらを使用するかを決める前に宿題をするだけです。
C++でコーディングしている場合、ブーストは非常に簡単です。私はいくつかの低レベルのライブラリを使用していますが、それらは不可欠です。私のコードを簡単に見ると、shared_ptr、program_options、regex、bind、serialization、foreach、property_tree、filesystem、tokenizer、さまざまなイテレーター拡張機能、alogrithm、およびmem_fnがわかります。これらは主に低レベルの機能であり、実際にコンパイラに組み込まれるべきです。一部のブーストライブラリは非常に汎用的です。彼らがあなたが望むことをするようにするのは仕事かもしれませんが、それは価値があります。
Pocoは、いくつかの非常に具体的な一般的なタスクの機能を提供するユーティリティクラスのコレクションです。ライブラリはよく書かれていて直感的です。ドキュメントを勉強したり、愚かなテストプログラムを書いたりするのに多くの時間を費やす必要はありません。現在、Logger、XML、Zip、およびNet/SMTPを使用しています。 libxml2が最後に私をいらいらさせたとき、私はPocoを使い始めました。私が使用できる他のクラスがありますが、試していません。 Data :: MySQL（mysql ++に満足しています）およびNet :: HTTP（libCURLに満足しています）。最終的には残りのPocoを試しますが、現時点ではそれは優先事項ではありません。
多くのPOCOユーザーは、Boostと共にBoostを使用すると報告しているため、両方のプロジェクトの人々にインセンティブがあることは明らかです。 Boostは高品質のライブラリのコレクションです。しかし、それはフレームワークではありません。 ACEに関しては、過去に使用したことがあり、デザインが気に入らなかった。さらに、古代の非準拠コンパイラのサポートにより、コードベースがtheい形になりました。
POCOを実際に区別するのは、スケーリングする設計と、JavaまたはC＃で得られるライブラリの豊富な可用性を備えたインターフェイスです。現時点では、POCOで最も深刻に欠けているのは非同期IOです。
リアルタイムの制約がある非常に高性能なデータ収集アプリケーションにACEを使用しました。単一のスレッドが、30以上のTCP/ICソケット接続とシリアルポートからのI/Oを処理します。コードは32ビットと64ビットの両方のLinuxで実行されます。私が使用した多くのACEクラスのいくつかは、ACE_Reactor、ACE_Time_Value、ACE_Svc_Handler、ACE_Message_Queue、ACE_Connectorです。 ACEはプロジェクトの成功の重要な要因でした。 ACEクラスの使用方法を理解するにはかなりの努力が必要です。私はACEについて書かれたすべての本を持っています。私たちのシステムの機能を拡張しなければならないときはいつでも、通常、何をすべきかを研究するのに少し時間がかかり、必要なコードの量は非常に少なくなります。 ACEの信頼性は非常に高いことがわかりました。また、Boostのコードも少し使用しています。 Boostには同じ機能がありません。どちらかまたは両方のライブラリを使用します。
私は最近、新しい仕事を得て、ACEとTAOを使用するプロジェクトに取り組んでいます。まあ、私が言えることは、ACEとTAOが機能し、それらのタスクを完全に達成するということです。しかし、図書館の全体的な組織と設計は非常に困難です...
たとえば、ACEの主要部分は、「ACE_」で始まる数百のクラスで構成されています。彼らは何十年も名前空間を無視してきたようです。
さらに、ACEのクラス名の多くは有用な情報も提供しません。または、ACE_Dev_Poll_Reactor_NotifyやACE_Proactor_Handle_Timeout_Upcallなどのクラスを使用できるクラスを推測できますか？
さらに、ACEのドキュメントは本当に不足しているので、難しい方法でACEを学習したいのでなければ（良いドキュメントがなければ本当に難しいです）、本当に必要な場合を除き、ACEの使用はお勧めしません [〜 ＃〜] tao [〜＃〜] for [〜＃〜] corba [〜＃〜] 、CORBAが不要な場合は、最新のライブラリを使用してください。
ACEソケットライブラリは堅牢です。ソケットの標準実装を移植しようとしている場合、間違いはありません。 ACEコードは厳格な開発パラダイムに準拠しています。より高いレベルの構造は、使用するのが少し混乱します。厳格なパラダイムにより、例外処理に異常が発生します。文字列値のペアが例外に渡され、ペアの1つがnullになると、例外がスローされて例外がスローされます。デバッグ時には、クラスの階層化の深さは面倒です。私は他のライブラリを試したことがないので、インテリジェントなコメントをすることはできません。
Boost開発者でもあるC++標準委員会の人々のおかげで、Boostは「STLに近い」ステータスを享受しています。 PocoとACEはそのメリットを享受できません。また、私の逸話的な経験から、Boostはより広く普及しています。
ただし、POCO全体は、ネットワーク型のものを中心にしています。私はBoostに固執しているので、そこであなたを助けることはできませんが、Boostのプラスは（比較的）広範囲に使用されていることです。
Boostは素晴らしいです。POCOについては良いことしか聞いていませんが（使用したことはありません）、ACEは好きではなく、将来的にはそれを避けます。あなたはACEのファンを見つけるでしょうが、あなたはブーストやポコ（IME）で得る傾向のない多くの中傷者も見つけるでしょう、私にはACEが最良のツールではないという明確なシグナルを送ります錫の上）。
これらのうち、ACEを実際に使用したことがあるだけです。 ACEは、クロスプラットフォームのエンタープライズネットワーキングアプリケーション向けの優れたフレームワークです。非常に用途が広くスケーラブルであり、TABとJAWSが付属しているため、ORBやWebベースのアプリケーションを迅速かつ強力に開発できます。
それに慣れるのはやや困難かもしれませんが、それに関する多くの文献があり、利用可能な商用サポートがあります。
ただし、やや重いので、小規模のアプリの場合はちょっとやり過ぎかもしれません。 POCOの概要を読むと、組み込みシステムで実行できるシステムを目指しているように聞こえるので、もっと軽い方法で使用できると思います。私は今それを旋回するかもしれません：P
それは本当に意見の問題だと思う、ほとんど正しい答えはありません。
移植可能なWin32/Linuxサーバーコード（15年以上）を書いた私の経験では、ブースト/ ACEが不必要に肥大化していることがわかり、それらがもたらすわずかな利点のためにメンテナンスハザード（別名「dll hell」）を導入しています。
ACEも恐ろしく古くなっているようです。これは90年代に「cプログラマー」によって作成された「c ++ライブラリ」であり、私の意見からも明らかです。そういうことが起こります。私は今、Picoで書かれたプロジェクトをリエンジニアリングしています。ACEのアイデアに完全に準拠しているように思えますが、より現代的な観点では、それほど良くはありません。
いずれの場合でも、高性能で効率的で洗練されたサーバー通信を行うには、いずれも使用しないほうがよい場合があります。