ACE vs Boost vs POCO [fechado]

96

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.

Rahul
fonte
3
ACE é o "canivete suíço de programação de rede definitivo" para programação C ++, mas da última vez que verifiquei, ele também era uma grande dependência de monstro em si mesmo.
nenhum

Respostas:

90

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.

Dani van der Meer
fonte
1
Pelo pouco que aprendi sobre POCO, as coisas não parecem se encaixar: 1. boost thread parece muito mais versátil e avançado. 2. POCO é mais versátil de que maneiras? 3. Estou interessado apenas em networking. XML e banco de dados não me preocupam. 4. Integrado como uma biblioteca? Não tenho certeza se isso é uma coisa boa ou ruim? 5. Boost, eu acredito (e isso vale para boost :: asio também) também é bastante multiplataforma.
rahul
@Rahul tentei responder a alguns de seus pontos na resposta.
Dani van der Meer
Não olhei para o POCO recentemente, mas quando olhei para ele alguns anos atrás, fiquei desanimado pelo fato de que os componentes pareciam usar uma mistura de licenças. Alguns usavam a licença Boost, outros eram GPL. Algumas das coisas de criptografia exigiam uma licença para uso comercial. Não sei qual é a situação atual de licenciamento com o POCO, mas gostaria de examinar isso com cuidado antes de usá-lo.
Ferruccio
10
POCO é totalmente licenciado sob a licença Boost (para referência futura).
Brendan Long
1
Uma vantagem do Poco é que ele tem tempos de compilação muito mais rápidos. Como o Boost geralmente depende de muitos e muitos códigos nos cabeçalhos, os tempos de compilação podem ser lentos. Com o poco, há mais links dinâmicos que reduzem o tempo de compilação. Também há uma vantagem de segurança, pois o usuário pode atualizar o arquivo .so / .dll sem ter que recompilar tudo.
Ericcurtin de
27

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.


fonte
Boa descrição, obrigado.
Amir Naghizadeh
21

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.

Alex
fonte
11

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.

Prumo
fonte
10

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.

Smerlin
fonte
7

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.

Dan
fonte
6

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.

rlbond
fonte
4

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).

Patrick
fonte
10
O ACE existe há muito tempo e teve que oferecer suporte a muitas plataformas legadas ao longo dos anos. Esta é uma das razões pelas quais não é tão moderno Boost, por exemplo. Uma grande quantidade de pesquisas e literatura extremamente úteis saiu do ACE (consulte o currículo de Doug Schmidt) que outros foram capazes de alavancar e construir. Naturalmente, outros aprenderão com os erros cometidos em bibliotecas mais antigas e os aperfeiçoarão. Outros também surgirão com maneiras completamente novas de fazer coisas semelhantes. Não seja muito duro com o ACE. Também sou um grande fã do Boost. Reconheço que nunca usei POCO.
Anulado em
6
O ACE foi iniciado em uma época em que os compiladores eram muito incompatíveis (nenhum padrão existia ainda), e os modelos eram um pesadelo completo (1996/1997) e havia uma centena de plataformas do tipo Unix. Avaliei ACE + TAO para um projeto - acabamos optando pelo OmniORB, o TAO era tão imaturo que quebrava a cada novo lançamento. ACE, por outro lado, era uma rocha. Mostra a idade, em termos de configuração de biblioteca, mas é sólido e tem um grande número de seguidores. Eu temia um pouco do ditador benevolente, no entanto - se Schmidt alguma vez fizesse isso, ACE poderia ser um problema. Não tenho essa sensação com Boost.
Chris K
3

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

Gerald
fonte
0

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.

ao
fonte