ACE - Boost - POCO [kapalı]


97

Bir süredir Boost C ++ Kitaplıkları ile çalışıyorum . Ağ programlama için Boost Asio C ++ kitaplığını kesinlikle seviyorum . Ancak diğer iki kütüphaneyle tanıştım : POCO ve Adaptive Communication Environment (ACE) çerçevesi . Her birinin iyi ve kötü yönlerini bilmek isterim.


3
ACE, C ++ programlama için "nihai ağ programlama İsviçre çakısı" dır, ancak en son kontrol ettim, aynı zamanda başlı başına devasa bir bağımlılıktı.
yok

Yanıtlar:


91

Rdbound'un dediği gibi, Boost'un "yakın STL" durumu vardır. Dolayısıyla , başka bir kitaplığa ihtiyacınız yoksa , Boost'a bağlı kalın. Ancak, durumum için bazı avantajları olduğu için POCO kullanıyorum . POCO IMO ile ilgili güzel şeyler:

  • Daha iyi iş parçacığı kitaplığı, özellikle bir Aktif Yöntem uygulaması. Ayrıca iş parçacığı önceliğini ayarlayabilmenizi de seviyorum.

  • Daha kapsamlı ağ kitaplığı boost::asio. Ancak boost::asioaynı zamanda çok iyi bir kütüphane.

  • Birkaç isim vermek gerekirse XML ve veritabanı arayüzü gibi Boost'ta olmayan işlevler içerir.

  • Boost'tan tek bir kitaplık olarak daha entegre edilmiştir.

  • Temiz, modern ve anlaşılır C ++ koduna sahiptir. Anlaması çoğu Boost kütüphanesinden çok daha kolay buluyorum (ama ben bir şablon programlama uzmanı değilim :)).

  • Bir çok platformda kullanılabilir.

POCO'nun bazı dezavantajları şunlardır:

  • Sınırlı belgeleri vardır. Bu, kaynağın anlaşılmasının kolay olması gerçeğiyle biraz dengeleniyor.

  • Boost'tan çok daha küçük bir topluluğa ve kullanıcı tabanına sahiptir. Yani örneğin Stack Overflow'a bir soru sorarsanız, yanıt alma şansınız Boost'tan daha azdır.

  • Yeni C ++ standardı ile ne kadar iyi entegre edileceği görülecek. Bunun Boost için bir sorun olmayacağından eminiz.

ACE'yi hiç kullanmadım, bu yüzden gerçekten yorum yapamam. Duyduğuma göre, insanlar POCO'yu ACE'den daha modern ve kullanımı daha kolay buluyor.

Rahul'ın yorumlarına bazı cevaplar:

  1. Çok yönlü ve gelişmiş hakkında bilgim yok. POCO iş parçacığı kitaplığı, Boost: ActiveMethodve Activity, ve'de olmayan bazı işlevler sağlar ThreadPool. IMO POCO ipliklerinin kullanımı ve anlaşılması da daha kolaydır, ancak bu öznel bir konudur.

  2. POCO ağ kitaplığı ayrıca HTTP ve SSL gibi daha yüksek seviyeli protokoller için destek sağlar (muhtemelen aynı zamanda boost::asio, ancak emin değilim?).

  3. Yeterince adil.

  4. Entegre kütüphane, tutarlı kodlama, belgeleme ve genel "görünüm ve his" avantajına sahiptir.

  5. Çapraz platform olması POCO'nun önemli bir özelliğidir, bu Boost ile ilgili bir avantaj değildir.

Yine, muhtemelen sadece ihtiyacınız olan bazı işlevleri sağlıyorsa ve bu Boost'ta değilse POCO'yu düşünmelisiniz.


1
POCO hakkında çok az şey öğrendiklerime göre, bazı şeyler bir araya gelmiyor: 1. boost iş parçacığı çok daha çok yönlü ve gelişmiş görünüyor. 2. POCO hangi yönlerden daha çok yönlüdür? 3. Sadece ağ kurma ile ilgileniyorum. XML ve veritabanı beni ilgilendirmiyor. 4. Tek bir kitaplık olarak entegre mi? Bunun iyi mi yoksa kötü mü olduğundan emin değilim? 5. Boost'un (ve bu boost :: asio için de geçerli) oldukça çapraz platform olduğuna inanıyorum.
rahul

@Rahul cevapta bazı noktalarınızı cevaplamaya çalıştım.
Dani van der Meer

Son zamanlarda POCO'ya bakmadım, ancak birkaç yıl önce ona baktığımda bileşenlerin bir lisans karışımı kullanıyor gibi görünmesi beni erteledi. Bazıları Boost lisansını kullandı, diğerleri GPL idi. Şifreleme malzemelerinin bazıları ticari kullanım için bir lisans gerektiriyordu. POCO ile mevcut lisanslama durumunun ne olduğunu bilmiyorum, ancak kullanmadan önce buna dikkatlice bakardım.
Ferruccio

10
POCO, tamamen Boost lisansı altında lisanslanmıştır (ileride başvurmak üzere).
Brendan Long

1
Poco'nun bir avantajı, çok daha hızlı derleme sürelerine sahip olmasıdır. Boost genellikle başlıklarda çok sayıda koda dayandığından, derleme süreleri yavaş olabilir. Poco ile derleme süresini azaltan daha dinamik bağlantı vardır. Kullanıcı her şeyi yeniden derlemek zorunda kalmadan .so / .dll dosyasını güncelleyebildiği için ayrıca bir güvenlik avantajı da vardır.
ericcurtin

28

Üçünü de kullandım, işte benim 0,02 dolarım.

Doug Schmidt'e oy vermek ve yaptığı her işe saygı duymak istiyorum ama dürüst olmak gerekirse ACE'yi biraz hatalı ve kullanması zor buluyorum. Bence kütüphanenin yeniden başlatılması gerekiyor. Bunu söylemek zor, ancak TAO'yu kullanmak için zorlayıcı bir neden olmadıkça veya hem Unix varyantlarında hem de Windows'ta C ++ çalıştırmak için tek bir kod tabanına ihtiyacınız olmadığı sürece ACE'den şimdilik uzak dururum. TAO, bir dizi zor problem için muhteşemdir, ancak öğrenme eğrisi yoğun ve CORBA'nın bir dizi eleştirmeni olmasının bir nedeni var. Sanırım ikisini de kullanmaya karar vermeden önce ödevini yap.

C ++ ile kodlama yapıyorsanız, aklımda güçlendirme hiç akıllıca değil. Bazı düşük seviyeli kütüphaneleri kullanıyorum ve onları gerekli buluyorum. Kodumun hızlı bir görünümü, shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, dosya sistemi, belirteç, çeşitli yineleyici uzantıları, alogrithm ve mem_fn'yi ortaya çıkarır. Bunlar çoğunlukla derleyicide olması gereken düşük seviyeli işlevlerdir. Bazı destek kitaplıkları çok geneldir; Onlara istediğinizi yaptırmak iş olabilir, ama buna değer.

Poco, bazı çok somut ortak görevler için işlevsellik sağlayan bir yardımcı sınıflar koleksiyonudur. Kütüphanelerin iyi yazılmış ve sezgisel olduğunu düşünüyorum. Belgeleme çalışmak veya aptalca test programları yazmak için fazla zaman harcamak zorunda değilim. Şu anda Logger, XML, Zip ve Net / SMTP kullanıyorum. Poco'yu libxml2 beni son kez rahatsız ettiğinde kullanmaya başladım. Kullanabileceğim ancak denemediğim başka sınıflar da var, örneğin Data :: MySQL (mysql ++ ile mutluyum) ve Net :: HTTP (libCURL'den memnunum). Sonunda Poco'nun geri kalanını deneyeceğim, ancak bu noktada bu bir öncelik değil.


İyi açıklama, teşekkürler.
Amir Naghizadeh

21

Birçok POCO kullanıcısı bunu Boost ile birlikte kullandığını bildirmektedir, bu nedenle her iki projede de insanlar için teşviklerin olduğu açıktır. Boost, yüksek kaliteli kitaplıklardan oluşan bir koleksiyondur. Ancak bu bir çerçeve değil. ACE'ye gelince, bunu geçmişte kullandım ve tasarımından hoşlanmadım. Ek olarak, eski uyumlu olmayan derleyicilere verdiği destek, kod tabanını çirkin bir şekilde şekillendirdi.

POCO'yu gerçekten ayıran şey, ölçeklenen bir tasarım ve Java veya C # ile elde edilenleri anımsatan zengin kitaplık kullanılabilirliğine sahip bir arayüzdür. Şu anda, POCO'dan en çok eksik olan şey asenkron IO'dur.


11

ACE'yi gerçek zamanlı kısıtlamalara sahip çok yüksek performanslı bir veri toplama uygulaması için kullandım. Tek bir iş parçacığı, otuzdan fazla TCP / IC soket bağlantısından ve bir seri bağlantı noktasından G / Ç işlemlerini gerçekleştirir. Kod hem 32 hem de 64 bit Linux'ta çalışır. Kullandığım birçok ACE sınıfından birkaçı ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE, projemizin başarısında kilit bir faktördü. ACE sınıflarının nasıl kullanılacağını anlamak önemli bir çaba gerektirir. ACE hakkında yazılmış tüm kitaplarım var. Ne zaman işlevselliği genişletmek zorunda olsam, sistemimiz genellikle ne yapacağımı incelemek biraz zaman alır ve bu durumda gerekli kod miktarı çok azdır. ACE'yi çok güvenilir buldum. Ayrıca Boost'tan biraz kod kullanıyorum. Boost'ta aynı işlevi görmüyorum.


10

Yakın zamanda yeni bir iş buldum ve ACE ve TAO kullanan bir proje üzerinde çalıştım. Söyleyebileceğim, ACE ve TAO'nun çalıştığı ve görevlerini tam olarak yerine getirdiği. Ancak kütüphanelerin genel organizasyonu ve tasarımı oldukça ürkütücü ...

Örneğin, ACE'nin ana kısmı "ACE_" ile başlayan yüzlerce sınıftan oluşur. Onlarca yıldır ad alanlarını görmezden gelmişler gibi görünüyor.

Ek olarak, ACE'nin sınıf adlarının çoğu da yararlı bilgiler sağlamaz. Veya hangi sınıfların sevildiğini ACE_Dev_Poll_Reactor_Notifyveya ACE_Proactor_Handle_Timeout_Upcallne için kullanılabileceğini tahmin edebilir misiniz ?

Additonally ACE dokümantasyonu gerçekten Ace zor yoldan öğrenmek isteyen yüzden sürece, eksik (bir faydası belgeler olmadan gerçekten zor ..) Gerçekten ihtiyacınız olmadıkça, ben, ACE kullanarak tavsiye ETMEM TAO için CORBA Eğer varsa, CORBA'ya ihtiyacınız yok, devam edin ve bazı modern kütüphaneleri kullanın ..


7

ACE soket kitaplıkları sağlamdır. Standart bir soket uygulamasını taşımaya çalışıyorsanız, yanlış gidemezsiniz. ACE kodu, katı bir geliştirme paradigmasına bağlı kalır. Daha yüksek seviyeli yapıların kullanımı biraz kafa karıştırıcıdır. Katı paradigma, istisna işleme ile bazı anormalliklere neden olur. Dize değer çiftlerinin bir istisnaya geçirildiği ve çiftlerden birinin boş olduğu durumlar, istisnada sizi şaşırtacak bir istisna atılmasına neden olur. Sınıf katmanlamanın derinliği, hata ayıklama sırasında sıkıcıdır. Diğer kütüphaneleri hiç denemedim, bu yüzden akıllıca bir yorum yapamam.


6

Boost, aynı zamanda Boost geliştiricileri olan C ++ standartlar komitesindeki kişi sayısı nedeniyle "STL'ye yakın" statüsüne sahiptir. Poco ve ACE bu avantajdan yararlanmıyor ve benim anekdot deneyimlerime göre Boost daha yaygın.

Bununla birlikte, bir bütün olarak POCO, ağ tipi şeyler etrafında daha merkezlenmiştir. Boost'a sadık kalıyorum, bu yüzden size yardımcı olamam, ancak Boost'un artı (nispeten) yaygın kullanımıdır.


4

Boost harika, sadece POCO hakkında iyi şeyler duydum (ama hiç kullanmadım) ama ACE'yi sevmiyorum ve gelecekte bundan kaçınacağım. ACE hayranları bulacak olsanız da, güçlendirme veya poco (IME) ile elde etme eğiliminde olmadığınız birçok kötüleyici de bulacaksınız, bana ACE'nin en iyi araç olmadığına dair net bir sinyal gönderiyor (her ne kadar teneke üzerinde).


10
ACE çok uzun zamandır ortalıkta ve yıllar boyunca birçok eski platformu desteklemek zorunda kaldı. Örneğin, modern Boost kadar olmamasının nedenlerinden biri budur. ACE'den (bkz. Doug Schmidt'in Özgeçmişi) başkalarının yararlanıp geliştirebildiği çok sayıda yararlı araştırma ve literatür ortaya çıktı. Doğal olarak, diğerleri eski kütüphanelerde yapılan hatalardan ders çıkaracak ve onları geliştirecek. Diğerleri de benzer şeyler yapmanın tamamen yeni yollarını bulacaklar. ACE konusunda çok sert olmayın. Ben de büyük bir Boost hayranıyım. Kuşkusuz, POCO'yu hiç kullanmadım.
Boşluk

6
ACE, derleyicilerin çok uyumsuz olduğu (henüz bir standardın bulunmadığı) ve şablonların tam bir kabus olduğu (1996/1997) ve yüzlerce Unix benzeri platformun bulunduğu bir zamanda başlatıldı. Bir proje için ACE + TAO'yu değerlendirdim - sonunda OmniORB'a karar verdik, TAO o kadar olgunlaşmamıştı ki her yeni sürümde bozuldu. Öte yandan ACE bir kayaydı. Kütüphane düzeni açısından yaşını gösteriyor, ancak sağlam ve büyük bir takipçi kitlesi var. Ancak yardımsever bir diktatörden biraz korkuyordum - eğer Schmidt bir gün çizmeye kalkarsa, ACE sorun olabilir. Boost ile bu hissi yaşamıyorum.
Chris K

3

Bunlardan sadece gerçekten ACE kullandım. ACE, platformlar arası kurumsal ağ uygulamaları için harika bir çerçevedir. Son derece çok yönlü ve ölçeklenebilir ve ORB ve / veya Web tabanlı uygulamaların hızlı ve güçlü bir şekilde geliştirilmesi için TAO ve JAWS ile birlikte gelir.

Hızlanmak biraz göz korkutucu olabilir, ancak bununla ilgili çok sayıda literatür ve ticari destek mevcut.

Yine de biraz ağır, bu nedenle daha küçük ölçekli uygulamalar için biraz abartılı olabilir. POCO'nun özetini okurken, gömülü sistemlerde çalıştırılabilecek bir sistemi hedefliyorlarmış gibi geliyor, bu yüzden çok daha hafif bir şekilde kullanılabileceğini varsayıyorum. Şimdi bir koşuşturma verebilirim: P


0

Bunun gerçekten bir fikir meselesi olduğunu düşünüyorum, pek doğru bir cevap yok.

Taşınabilir Win32 / Linux sunucu kodu yazma konusundaki deneyimime göre (15+ yıl), kişisel olarak boost / ACE'yi gereksiz yere şişirilmiş buluyorum ve sağladıkları küçük avantaj nedeniyle bakım tehlikeleri (başka bir deyişle "dll cehennemi" olarak bilinir) ortaya çıkardı.

ACE de korkunç derecede modası geçmiş görünüyor, 90'lı yıllarda "c programcıları" tarafından yazılmış bir "c ++ kitaplığı" ve bence gerçekten gösteriyor. Öyle oluyor, şu anda Pico ile yazılan projeyi yeniden tasarlıyorum, bana tamamen ACE fikrini takip ediyor gibi görünüyor, ama daha çağdaş terimlerle, bunda daha iyi değil.

Her durumda, yüksek performanslı, verimli, zarif sunucu iletişimi için bunların hiçbirini kullanmamanız daha iyi olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.