ACE vs Boost vs POCO [fechado]

Tenho trabalhado com as Bibliotecas Boost C ++ há algum tempo. Eu absolutamente amo a biblioteca Boost Asio C ++ para programação de rede. No entanto, fui apresentado a duas outras bibliotecas: a estrutura POCO e Adaptive Communication Environment (ACE) . Eu gostaria de saber o que há de bom e de ruim em cada um.

Como disse o rdbound, Boost tem um status "próximo a STL". Portanto, se você não precisa de outra biblioteca, use o Boost. No entanto, eu uso o POCO porque tem algumas vantagens para a minha situação. As coisas boas sobre POCO IMO:

• Melhor biblioteca de threads, especialmente uma implementação de método ativo. Eu também gosto do fato de que você pode definir a prioridade do thread.

• Biblioteca de rede mais abrangente do que boost::asio. No entanto, boost::asiotambém é uma biblioteca muito boa.

• Inclui funcionalidades que não estão no Boost, como XML e interface de banco de dados, para citar alguns.

• É mais integrado como uma biblioteca do que Boost.

• Possui código C ++ limpo, moderno e compreensível. Acho muito mais fácil de entender do que a maioria das bibliotecas Boost (mas não sou um especialista em programação de modelos :)).

• Ele pode ser usado em várias plataformas.

Algumas desvantagens do POCO são:

• Possui documentação limitada. Isso é um pouco compensado pelo fato de que a fonte é fácil de entender.

• Ele tem uma comunidade e uma base de usuários muito menores do que, digamos, o Boost. Então, se você colocar uma pergunta no Stack Overflow, por exemplo, suas chances de obter uma resposta são menores do que no Boost

• Resta saber como ele será integrado ao novo padrão C ++. Você sabe com certeza que não será um problema para Boost.

Eu nunca usei o ACE, então não posso comentar sobre isso. Pelo que ouvi, as pessoas acham o POCO mais moderno e fácil de usar do que o ACE.

Algumas respostas aos comentários de Rahul:

1. Não conheço versátil e avançado. A biblioteca de thread POCO fornece algumas funcionalidades que não estão no Boost: ActiveMethode Activity, e ThreadPool. Os tópicos IMO POCO também são mais fáceis de usar e entender, mas isso é uma questão subjetiva.

2. A biblioteca de rede POCO também oferece suporte para protocolos de nível superior como HTTP e SSL (possivelmente também em boost::asio, mas não tenho certeza?).

3. Justo.

4. A biblioteca integrada tem a vantagem de ter codificação, documentação e "aparência" geral consistentes.

5. Ser multiplataforma é uma característica importante do POCO, isso não é uma vantagem em relação ao Boost.

Novamente, você provavelmente só deve considerar o POCO se ele fornecer alguma funcionalidade de que você precisa e não estiver no Boost.

Usei todos os três, então aqui está meu $ 0,02.

Eu realmente quero votar em Doug Schmidt e respeitar todo o trabalho que ele fez, mas para ser honesto, eu acho o ACE um pouco problemático e difícil de usar. Acho que essa biblioteca precisa ser reiniciada. É difícil dizer isso, mas eu me afastaria do ACE por enquanto, a menos que haja uma razão convincente para usar TAO, ou você precise de uma única base de código para executar C ++ em variantes Unix e Windows. TAO é fabuloso para uma série de problemas difíceis, mas a curva de aprendizado é intensa e há uma razão pela qual CORBA tem vários críticos. Acho que apenas faça sua lição de casa antes de tomar a decisão de usar qualquer um deles.

Se você está programando em C ++, o boost é, para mim, um acéfalo. Eu uso várias bibliotecas de baixo nível e as considero essenciais. Um rápido grep do meu código revela shared_ptr, program_options, regex, bind, serialização, foreach, property_tree, sistema de arquivos, tokenizer, várias extensões de iterador, alogrithm e mem_fn. Em sua maioria, são funcionalidades de baixo nível que realmente deveriam estar no compilador. Algumas bibliotecas boost são muito genéricas; pode ser difícil fazer com que eles façam o que você quer, mas vale a pena.

Poco é uma coleção de classes utilitárias que fornecem funcionalidade para algumas tarefas comuns muito concretas. Acho que as bibliotecas são bem escritas e intuitivas. Não preciso perder muito tempo estudando documentação ou escrevendo programas de teste idiotas. Atualmente estou usando Logger, XML, Zip e Net / SMTP. Comecei a usar Poco quando libxml2 me irritou pela última vez. Existem outras classes que eu poderia usar, mas não tentei, por exemplo, Data :: MySQL (estou feliz com mysql ++) e Net :: HTTP (estou feliz com libCURL). Vou experimentar o resto do Poco eventualmente, mas isso não é uma prioridade neste momento.

Muitos usuários do POCO relatam usá-lo junto com o Boost, então é óbvio que há incentivos para as pessoas em ambos os projetos. Boost é uma coleção de bibliotecas de alta qualidade. Mas não é uma estrutura. Quanto ao ACE, já o usei no passado e não gostei do design. Além disso, seu suporte para antigos compiladores incompatíveis moldou a base do código de uma maneira feia.

O que realmente distingue o POCO é um design que pode ser dimensionado e uma interface com uma rica disponibilidade de biblioteca que lembra aquelas que se obtém com Java ou C #. No momento, o que falta mais agudamente no POCO é o IO assíncrono.

Usei o ACE para um aplicativo de aquisição de dados de alto desempenho com restrições de tempo real. Um único thread lida com E / S de mais de trinta conexões de soquete TCP / IC e uma porta serial. O código é executado em Linux de 32 e 64 bits. Algumas das muitas classes ACE que usei são ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE foi um fator chave para o sucesso do nosso projeto. É preciso um esforço significativo para entender como usar as classes ACE. Eu tenho todos os livros escritos sobre ACE. Sempre que preciso estender a funcionalidade de nosso sistema, normalmente leva algum tempo para estudar o que fazer e a quantidade de código necessária é muito pequena. Achei o ACE muito confiável. Também uso um pouco do código do Boost. Não vejo a mesma funcionalidade no Boost.

Recentemente, consegui um novo emprego e trabalho em um projeto que usa ACE e TAO. Bem, o que posso dizer é que ACE e TAO funcionam e realizam plenamente suas tarefas. Mas a organização geral e o design das bibliotecas são bastante assustadores ...

Por exemplo, a parte principal do ACE consiste em centenas de classes começando com "ACE_". Parece que eles têm ignorado os namespaces há décadas.

Além disso, muitos dos nomes de classe do ACE também não fornecem informações úteis. Ou você pode adivinhar quais aulas gostam ACE_Dev_Poll_Reactor_NotifyouACE_Proactor_Handle_Timeout_Upcall podem ser usadas?

Além disso, a documentação do ACE está realmente faltando, então a menos que você queira aprender ACE da maneira mais difícil (é realmente difícil sem nenhuma boa documentação ..), eu NÃO recomendaria usar o ACE, a menos que você realmente precise do TAO para CORBA , se você não precisa do CORBA, vá em frente e use algumas bibliotecas modernas.

As bibliotecas de soquetes ACE são sólidas. Se você está tentando portar uma implementação padrão de soquetes, não pode dar errado. O código ACE segue um paradigma de desenvolvimento rígido. Os contrutos de nível superior são um pouco confusos para usar. O paradigma rígido causa algumas anomolias com tratamento de exceções. Existem ou costumava haver situações em que pares de valores de string sendo passados ​​para uma exceção com um dos pares sendo nulo causa uma exceção que lança a exceção que o deixará confuso. A profundidade das camadas de classe é entediante durante a depuração. Nunca experimentei as outras bibliotecas, por isso não posso fazer um comentário inteligente.

O Boost desfruta de um status "próximo ao STL" devido ao número de pessoas no comitê de padrões C ++ que também são desenvolvedores do Boost. Poco e ACE não desfrutam desse benefício e, pela minha experiência anedótica, o Boost é mais difundido.

No entanto, POCO como um todo é mais centrado em coisas do tipo rede. Eu me limitei ao Boost, então não posso ajudá-lo, mas a vantagem do Boost é seu uso (relativamente) difundido.

Boost é ótimo, eu só ouvi coisas boas sobre POCO (mas nunca usei), mas não gosto de ACE e o evitaria no futuro. Embora você encontre fãs de ACE, você também encontrará muitos detratores que você não tende a obter com boost ou poco (IME), para mim isso envia um sinal claro de que ACE não é a melhor ferramenta (embora faça o que diz na lata).

Destes, só usei realmente o ACE. O ACE é uma ótima estrutura para aplicativos de rede corporativa de plataforma cruzada. É extremamente versátil e escalável e vem com TAO e JAWS para desenvolvimento rápido e poderoso de ORB e / ou aplicativos baseados na Web.

Aprender a usá-lo pode ser um pouco assustador, mas há muita literatura sobre ele e suporte comercial disponível.

É um pouco pesado, portanto, para aplicativos de menor escala, pode ser um pouco exagerado. Lendo o resumo do POCO, parece que eles estão buscando um sistema que possa ser executado em sistemas embarcados, então estou assumindo que pode ser usado de uma forma muito mais leve. Posso agora dar um giro: P

Acho que realmente é uma questão de opinião, dificilmente existe uma resposta certa.

Em minha experiência com a escrita de código de servidor Win32 / Linux portátil (mais de 15 anos), eu pessoalmente acho boost / ACE desnecessariamente inchado e apresenta riscos de manutenção (também conhecidos como "dll hell") pela pouca vantagem que eles oferecem.

ACE também parece estar terrivelmente desatualizado, é uma "biblioteca c ++" escrita por "programadores c" nos anos 90 e realmente se mostra na minha opinião. Acontece, neste momento estou a reengenharia do projecto escrito com o Pico, parece-me que segue totalmente a ideia do ACE, mas em termos mais contemporâneos, não muito melhor nisso.

Em qualquer caso, para comunicações de servidor elegantes, eficientes e de alto desempenho, seria melhor não usar nenhum deles.