ACE vs Boost vs POCO [chiuso]

Lavoro da un po 'di tempo con le librerie Boost C ++ . Adoro la libreria Boost Asio C ++ per la programmazione di rete. Tuttavia sono stato presentato ad altre due librerie: POCO e Adaptive Communication Environment (ACE) framework . Vorrei conoscere il bene e il male di ciascuno.

Come ha detto rdbound, Boost ha uno stato "near STL". Quindi, se non hai bisogno di un'altra libreria, attieniti a Boost. Tuttavia, uso POCO perché ha alcuni vantaggi per la mia situazione. Gli aspetti positivi di POCO IMO:

• Migliore libreria di thread, in particolare un'implementazione del metodo attivo. Mi piace anche il fatto che tu possa impostare la priorità del thread.

• Libreria di rete più completa di boost::asio. Comunque boost::asioè anche un'ottima libreria.

• Include funzionalità che non sono in Boost, come XML e l'interfaccia del database per citarne alcuni.

• È più integrato come una libreria rispetto a Boost.

• Ha un codice C ++ pulito, moderno e comprensibile. Lo trovo molto più facile da capire rispetto alla maggior parte delle librerie Boost (ma non sono un esperto di programmazione di modelli :)).

• Può essere utilizzato su molte piattaforme.

Alcuni svantaggi di POCO sono:

• Ha una documentazione limitata. Ciò in qualche modo compensato dal fatto che la fonte è facile da capire.

• Ha una comunità e una base di utenti molto più piccole rispetto, ad esempio, a Boost. Quindi, se metti una domanda su Stack Overflow, ad esempio, le tue possibilità di ottenere una risposta sono inferiori rispetto a Boost

• Resta da vedere come sarà integrato bene con il nuovo standard C ++. Sai per certo che non sarà un problema per Boost.

Non ho mai usato ACE, quindi non posso davvero commentarlo. Da quello che ho sentito, le persone trovano POCO più moderno e più facile da usare di ACE.

Alcune risposte ai commenti di Rahul:

1. Non so se sia versatile e avanzato. La libreria di thread POCO fornisce alcune funzionalità che non sono in Boost: ActiveMethode Activity, e ThreadPool. Anche i thread IMO POCO sono più facili da usare e da capire, ma questa è una questione soggettiva.

2. La libreria di rete POCO fornisce anche supporto per protocolli di livello superiore come HTTP e SSL (forse anche in boost::asio, ma non ne sono sicuro?).

3. Giusto.

4. La libreria integrata ha il vantaggio di avere codifica, documentazione e "aspetto" generale coerenti.

5. Essere multipiattaforma è una caratteristica importante di POCO, questo non è un vantaggio in relazione a Boost.

Di nuovo, dovresti probabilmente considerare POCO solo se fornisce alcune funzionalità di cui hai bisogno e che non sono in Boost.

Li ho usati tutti e tre, quindi ecco i miei $ 0,02.

Voglio davvero votare per Doug Schmidt e rispettare tutto il lavoro che ha fatto, ma ad essere sincero trovo ACE leggermente bacato e difficile da usare. Penso che la libreria abbia bisogno di un riavvio. È difficile dirlo, ma per ora eviterei ACE a meno che non ci sia un motivo convincente per usare TAO, o che tu abbia bisogno di una singola base di codice per eseguire C ++ su entrambe le varianti Unix e Windows. TAO è favoloso per una serie di problemi difficili, ma la curva di apprendimento è intensa e c'è una ragione per cui CORBA ha un numero di critici. Immagino che fai i compiti prima di decidere di utilizzare entrambi.

Se stai programmando in C ++, boost è nella mia mente un gioco da ragazzi. Uso numerose librerie di basso livello e le trovo essenziali. Un rapido grep del mio codice rivela shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, varie estensioni iteratori, alogrithm e mem_fn. Queste sono per lo più funzionalità di basso livello che dovrebbero davvero essere nel compilatore. Alcune librerie boost sono molto generiche; può essere faticoso convincerli a fare quello che vuoi, ma ne vale la pena.

Poco è una raccolta di classi di utilità che forniscono funzionalità per alcune attività comuni molto concrete. Trovo che le librerie siano ben scritte e intuitive. Non devo dedicare molto tempo allo studio della documentazione o alla scrittura di stupidi programmi di test. Attualmente sto utilizzando Logger, XML, Zip e Net / SMTP. Ho iniziato a usare Poco quando libxml2 mi ha irritato per l'ultima volta. Ci sono altre classi che potrei usare ma non ho provato, ad esempio Data :: MySQL (sono soddisfatto di mysql ++) e Net :: HTTP (sono soddisfatto di libCURL). Alla fine proverò il resto di Poco, ma a questo punto non è una priorità.

Molti utenti POCO riferiscono di utilizzarlo insieme a Boost, quindi è ovvio che ci sono incentivi per le persone in entrambi i progetti. Boost è una raccolta di librerie di alta qualità. Ma non è un quadro. Per quanto riguarda ACE, l'ho usato in passato e non mi è piaciuto il design. Inoltre, il suo supporto per antichi compilatori non conformi ha modellato la base del codice in modo orribile.

Ciò che distingue davvero POCO è un design scalabile e un'interfaccia con una ricca disponibilità di librerie che ricorda quelle che si ottengono con Java o C #. In questo momento, la cosa più gravemente mancante da POCO è l'IO asincrono.

Ho utilizzato ACE per un'applicazione di acquisizione dati ad altissime prestazioni con vincoli di tempo reale. Un singolo thread gestisce l'I / O da oltre trenta connessioni socket TCP / IC e una porta seriale. Il codice viene eseguito su Linux a 32 e 64 bit. Alcune delle molte classi ACE che ho usato sono ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE è stato un fattore chiave per il successo del nostro progetto. Ci vuole uno sforzo significativo per capire come usare le classi ACE. Ho tutti i libri scritti su ACE. Ogni volta che ho dovuto estendere le funzionalità del nostro sistema, in genere ci vuole del tempo per studiare cosa fare e quindi la quantità di codice richiesta è molto ridotta. Ho trovato ACE molto affidabile. Uso anche un po 'di codice da Boost. Non vedo la stessa funzionalità in Boost.

Recentemente ho ottenuto un nuovo lavoro e lavoro a un progetto che utilizza ACE e TAO. Bene, quello che posso dire è che ACE e TAO lavorano e svolgono pienamente i loro compiti. Ma l'organizzazione generale e il design delle biblioteche sono piuttosto scoraggianti ...

Ad esempio, la parte principale di ACE è costituita da centinaia di classi che iniziano con "ACE_". Sembra che abbiano ignorato gli spazi dei nomi per decenni.

Inoltre, molti dei nomi di classi di ACE non forniscono informazioni utili. O puoi indovinare per quali classi piacciono ACE_Dev_Poll_Reactor_Notifyo ACE_Proactor_Handle_Timeout_Upcallpossono essere utilizzate?

Inoltre, la documentazione di ACE è davvero carente, quindi a meno che tu non voglia imparare ACE nel modo più duro (è davvero difficile senza una buona documentazione ..), NON consiglierei di usare ACE, a meno che tu non abbia davvero bisogno di TAO per CORBA , se tu non hai bisogno di CORBA, vai avanti e usa alcune librerie moderne ..

Le librerie di socket ACE sono solide. Se stai cercando di eseguire il port di un'implementazione standard dei socket non puoi sbagliare. Il codice ACE si attiene a un paradigma di sviluppo rigido. I controlli di livello superiore creano un po 'di confusione da usare. Il paradigma rigido causa alcune anomalie con la gestione delle eccezioni. Ci sono o ci sono state situazioni in cui le coppie di valori stringa passate in un'eccezione con una delle coppie null provoca un lancio di eccezione nell'eccezione che ti sconvolgerà. La profondità della stratificazione delle classi è noiosa durante il debug. Non ho mai provato le altre librerie quindi non posso fare un commento intelligente.

Boost gode di uno stato "near STL" a causa del numero di persone nel comitato per gli standard C ++ che sono anche sviluppatori Boost. Poco e ACE non godono di questo beneficio e dalla mia esperienza aneddotica Boost è più diffuso.

Tuttavia, POCO nel suo insieme è più incentrato su cose di tipo rete. Mi attengo a Boost quindi non posso aiutarti, ma il vantaggio di Boost è il suo uso (relativamente) diffuso.

Boost è fantastico, ho sentito solo cose positive su POCO (ma mai usato) ma non mi piace ACE e lo eviterei in futuro. Sebbene troverai fan di ACE, troverai anche molti detrattori che non tendi a ottenere con boost o poco (IME), per me questo invia un chiaro segnale che ACE non è lo strumento migliore (anche se fa quello che dice sulla latta).

Di questi ho usato solo ACE. ACE è un ottimo framework per applicazioni di rete aziendale multipiattaforma. È estremamente versatile e scalabile e viene fornito con TAO e JAWS per uno sviluppo rapido e potente di applicazioni ORB e / o basate sul Web.

Mettersi al passo può essere un po 'scoraggiante, ma c'è molta letteratura su di esso e supporto commerciale disponibile.

Tuttavia, è un po 'pesante, quindi per le app su scala ridotta potrebbe essere un po' eccessivo. Leggendo il riepilogo per POCO sembra che stiano puntando a un sistema che possa essere eseguito su sistemi embedded, quindi presumo che possa essere utilizzato in un modo molto più leggero. Ora posso fare un giro: P

Penso che sia davvero questione di un'opinione, difficilmente c'è una risposta giusta.

Nella mia esperienza con la scrittura di codice server Win32 / Linux portatile (15+ anni), personalmente trovo boost / ACE inutilmente gonfio e introduce rischi di manutenzione (altrimenti noti come "dll hell") per il piccolo vantaggio che danno.

ACE sembra anche essere orribilmente obsoleto, è una "libreria c ++" scritta da "programmatori c" negli anni '90 e secondo me si vede davvero. Accade così, in questo momento sto reingegnerizzando il progetto scritto con Pico, mi sembra che segua completamente l'idea ACE, ma in termini più contemporanei, non molto meglio in questo.

In ogni caso, per comunicazioni server ad alte prestazioni, efficienti ed eleganti, potrebbe essere meglio non utilizzarne nessuna.