私はかなり前からBoost C ++ Librariesを使用しています。ネットワークプログラミング用のBoost Asio C ++ライブラリが大好きです。ただし、POCOとAdaptive Communication Environment（ACE）フレームワークの 2つのライブラリが紹介されました。それぞれの長所と短所を知りたいのですが。
回答:
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のスレッドライブラリがブーストされていないいくつかの機能を提供します。ActiveMethodそしてActivity、とThreadPool。IMO POCOスレッドも使いやすく理解しやすいですが、これは主観的な問題です。
POCOネットワークライブラリは、HTTPやSSLなどの高レベルプロトコルのサポートも提供します（おそらくにもありますがboost::asio、よくわかりません）。
けっこうだ。
統合ライブラリには、一貫したコーディング、ドキュメント、および一般的な「ルックアンドフィール」があるという利点があります。
クロスプラットフォームであることはPOCOの重要な機能であり、これはBoostとの関係で利点にはなりません。
繰り返しますが、POCOは、必要な機能を提供し、それがBoostにない場合にのみ検討する必要があります。
私は3つすべてを使用したので、これは$ 0.02です。
私は本当にダグシュミットに投票し、彼が行ったすべての作業を尊重したいのですが、正直に言うと、ACEは少しバグがあり、使いにくいと思います。ライブラリは再起動が必要だと思います。これを言うのは難しいですが、TAOを使用する説得力のある理由がない限り、またはUnixのバリアントとWindowsの両方でC ++を実行するために単一のコードベースが必要でない限り、今のところACEを避けます。TAOは多くの困難な問題に対して素晴らしいですが、学習曲線は激しく、CORBAが多くの批評家を持っているのには理由があります。どちらを使うかを決める前に、宿題をするだけだと思います。
C ++でコーディングしている場合、ブーストは頭の中で非常に簡単です。私はいくつかの低レベルのライブラリを使用しており、それらが不可欠であると感じています。私のコードの簡単なgrepは、shared_ptr、program_options、regex、bind、serialization、foreach、property_tree、filesystem、tokenizer、さまざまなイテレーター拡張、alogrithm、およびmem_fnを明らかにします。これらは主に低レベルの機能であり、実際にはコンパイラーにあるべきです。いくつかのboostライブラリは非常に一般的です。彼らがあなたが望むことをするようにさせることは仕事であるかもしれません、しかしそれは価値があります。
Pocoは、いくつかの非常に具体的な一般的なタスクに機能を提供するユーティリティクラスのコレクションです。ライブラリはよく書かれていて直感的です。ドキュメントを勉強したり、ばかげたテストプログラムを書いたりするのに、多くの時間を費やす必要はありません。現在、Logger、XML、Zip、Net / SMTPを使用しています。libxml2が最後に私を苛立たせたとき、私はPocoを使い始めました。他にも使用できるが試していないクラスがあります。たとえば、Data :: MySQL（mysql ++には満足）やNet :: HTTP（libCURLには満足）などがあります。最終的にはPocoの残りの部分を試してみるつもりですが、現時点ではそれは優先事項ではありません。
多くのPOCOユーザーがBoostと一緒にそれを使用することを報告しているので、両方のプロジェクトの人々にインセンティブがあることは明らかです。Boostは、高品質のライブラリのコレクションです。しかし、それはフレームワークではありません。ACEは過去に使ったことがあり、デザインが気に入らなかった。さらに、古くなった非準拠コンパイラのサポートにより、コードベースが醜い形になっています。
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に使用できるか推測できますか？
Additonally、ACEのドキュメントは本当にあなたがACEに苦労して勉強したいので、場合を除き、不足している（それが何か良いドキュメントなしでは本当に難しいです。）あなたが本当に必要としない限り、私は、ACEを使用してお勧めしませんTAOのためにCORBAあなたがいる場合、 CORBAは必要ありません。先に進んで、最新のライブラリを使用してください。
ブーストは素晴らしいです、私はPOCOについて良いことだけを聞いたことがあります（しかし、決して使用しませんでした）が、私はACEが好きではないので、将来はそれを避けます。あなたはACEのファンを見つけるでしょうが、ブーストやポコ（IME）で得られる傾向があまりない中傷者もたくさん見つかりますが、ACEは最適なツールではないという明確なシグナルを私に送信します（それは言うことを行いますが）缶に）。
それらのうち、私が実際に使用したのはACEだけです。ACEは、クロスプラットフォームのエンタープライズネットワーキングアプリケーションに最適なフレームワークです。非常に用途が広くスケーラブルで、ORBやWebベースのアプリケーションをすばやく強力に開発するためのTAOとJAWSが付属しています。
それに慣れるのは少し難しいかもしれませんが、多くの文献があり、商用サポートも利用できます。
ただし、やや重いので、小規模のアプリの場合、少々やり過ぎかもしれません。POCOの要約を読んでいると、組み込みシステムで実行できるシステムを目指しているように思えるので、もっと簡単に使用できると思います。私はそれを旋回させるかもしれません：P
本当に意見の問題だと思います。正解はほとんどありません。
移植可能なWin32 / Linuxサーバーコード（15年以上）を書いた私の経験では、個人的にboost / ACEが不必要に肥大化していることを発見し、彼らが与える小さな利点のために保守の危険（別名「dll hell」）を引き起こしています。
ACEもひどく時代遅れのようです。90年代に「cプログラマー」によって書かれた「c ++ライブラリー」であり、私の意見ではそれが実際に示されています。たまたまそうなったのですが、現在、Picoで作成したプロジェクトをリエンジニアリングしています。ACEのアイデアに完全に従っているように見えますが、より現代的な言い方をすると、それほど優れていません。
いずれにせよ、高性能で効率的でエレガントなサーバー通信を実現するには、それらを使用しない方がよいでしょう。