저는 꽤 오랫동안 Boost C ++ Libraries 를 사용해 왔습니다. 저는 네트워크 프로그래밍을위한 Boost Asio C ++ 라이브러리 를 절대적으로 좋아합니다 . 그러나 저는 POCO 와 ACE (Adaptive Communication Environment) 프레임 워크 라는 두 개의 다른 라이브러리를 소개 받았습니다 . 각각의 장점과 단점을 알고 싶습니다.
답변:
rdbound가 말했듯이 Boost는 "near STL"상태입니다. 따라서 다른 라이브러리 가 필요 하지 않으면 Boost를 사용하십시오. 그러나 POCO 는 내 상황에 몇 가지 장점이 있기 때문에 사용 합니다. POCO IMO의 좋은 점 :
더 나은 스레드 라이브러리, 특히 Active Method 구현. 또한 스레드 우선 순위를 설정할 수 있다는 사실도 마음에 듭니다.
보다 포괄적 인 네트워크 라이브러리 boost::asio. 그러나 boost::asio또한 매우 좋은 라이브러리입니다.
XML 및 데이터베이스 인터페이스와 같이 Boost에없는 기능을 포함합니다.
Boost보다 하나의 라이브러리로 더 통합되어 있습니다.
깨끗하고 현대적이며 이해하기 쉬운 C ++ 코드가 있습니다. 대부분의 Boost 라이브러리보다 이해하기가 훨씬 쉽다는 것을 알았습니다 (하지만 템플릿 프로그래밍 전문가는 아닙니다 :)).
많은 플랫폼에서 사용할 수 있습니다.
POCO의 몇 가지 단점은 다음과 같습니다.
제한된 문서가 있습니다. 이것은 소스가 이해하기 쉽다는 사실에 의해 다소 상쇄됩니다.
Boost보다 커뮤니티와 사용자 기반이 훨씬 작습니다. 따라서 예를 들어 Stack Overflow에 질문을 올리면 답변을 얻을 가능성이 Boost보다 적습니다.
새로운 C ++ 표준과 얼마나 잘 통합 될지는 아직 지켜봐야합니다. Boost에 문제가되지 않을 것임을 확실히 알고 있습니다.
ACE를 사용한 적이 없어서 댓글을 달 수 없습니다. 내가들은 바에 따르면 사람들은 POCO가 ACE보다 더 현대적이고 사용하기 쉽다고 생각합니다.
Rahul의 의견에 대한 몇 가지 답변 :
나는 다재다능하고 진보 된 것에 대해 모른다. POCO 스레드 라이브러리는 Boost : ActiveMethod및 Activity, 및에 없는 일부 기능을 제공합니다 ThreadPool. IMO POCO 스레드도 사용하고 이해하기 쉽지만 이는 주관적인 문제입니다.
POCO 네트워크 라이브러리는 또한 HTTP 및 SSL과 같은 상위 수준 프로토콜에 대한 지원을 제공합니다 (에서도 가능 boost::asio하지만 확실하지 않습니까?).
그럴 수 있지.
통합 라이브러리는 일관된 코딩, 문서 및 일반적인 "모양과 느낌"을 갖는 이점이 있습니다.
크로스 플랫폼이라는 것은 POCO의 중요한 기능이며 Boost와 관련하여 이점이 아닙니다.
다시 말하지만, POCO가 필요한 기능을 제공하고 Boost에없는 경우에만 POCO를 고려해야합니다.
세 가지를 모두 사용 했으므로 여기 $ 0.02입니다.
나는 Doug Schmidt에게 투표하고 그가 한 모든 일을 존중하고 싶지만 솔직히 말해서 ACE는 약간 버그가 있고 사용하기 어렵다고 생각합니다. 라이브러리를 재부팅해야한다고 생각합니다. 이렇게 말하기는 어렵지만 TAO를 사용해야하는 설득력있는 이유가 없거나 Unix 변형과 Windows 모두에서 C ++를 실행하기 위해 단일 코드 기반이 필요하지 않는 한 지금은 ACE를 피하고 싶습니다. TAO는 많은 어려운 문제에 대해 훌륭하지만 학습 곡선이 강하고 CORBA가 많은 비평가를 갖는 이유가 있습니다. 둘 중 하나를 사용하기로 결정하기 전에 숙제를하는 것 같습니다.
C ++로 코딩하는 경우 부스트는 생각할 필요가 없습니다. 저는 많은 저수준 라이브러리를 사용하고 있으며 그것들이 필수적이라고 생각합니다. 내 코드의 빠른 grep은 shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, 파일 시스템, 토크 나이저, 다양한 반복기 확장, alogrithm 및 mem_fn을 보여줍니다. 이들은 대부분 컴파일러에 있어야하는 저수준 기능입니다. 일부 부스트 라이브러리는 매우 일반적입니다. 그들이 당신이 원하는 것을하도록하는 것은 일이 될 수 있지만, 그만한 가치가 있습니다.
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가 필요하지 않습니다. 최신 라이브러리를 사용하세요.
ACE 소켓 라이브러리는 견고합니다. 소켓의 표준 구현을 포팅하려는 경우 잘못 될 수 없습니다. ACE 코드는 엄격한 개발 패러다임을 고수합니다. 더 높은 수준의 구조는 사용하기에 약간 혼란 스럽습니다. 엄격한 패러다임은 예외 처리와 함께 일부 이상을 일으 킵니다. 문자열 값 쌍이 예외로 전달되고 쌍 중 하나가 null 인 경우 예외가 발생하여 예외가 발생하는 상황이 있거나 예전에는 있습니다. 디버깅 할 때 클래스 계층화의 깊이는 지루합니다. 나는 다른 라이브러리를 시도한 적이 없으므로 지적인 코멘트를 할 수 없습니다.
부스트는 훌륭합니다. 저는 POCO에 대한 좋은 소식 만 들었지만 (사용한 적이 없음) ACE가 마음에 들지 않아 앞으로 피할 것입니다. ACE의 팬을 찾을 수 있지만 부스트 또는 포코 (IME)를 사용하지 않는 경향이있는 많은 비방자를 찾을 수 있습니다. ACE가 최고의 도구가 아니라는 분명한 신호를 보냅니다. 주석에).
그 중에서 저는 ACE 만 사용 해본 적이 있습니다. ACE는 크로스 플랫폼 엔터프라이즈 네트워킹 애플리케이션을위한 훌륭한 프레임 워크입니다. 매우 다양하고 확장 가능하며 ORB 및 / 또는 웹 기반 애플리케이션의 빠르고 강력한 개발을 위해 TAO 및 JAWS와 함께 제공됩니다.
속도에 익숙해지는 것은 다소 어려울 수 있지만 이에 대한 많은 문헌과 상업적 지원이 가능합니다.
그러나 다소 무겁기 때문에 소규모 앱의 경우 약간의 과잉 일 수 있습니다. POCO에 대한 요약을 읽으면 임베디드 시스템에서 실행할 수있는 시스템을 목표로하는 것처럼 들리므로 훨씬 가벼운 방식으로 사용할 수 있다고 가정합니다. 이제 소용돌이를 줄 수 있습니다 : P
정말 의견의 문제라고 생각합니다. 정답은 거의 없습니다.
휴대용 Win32 / Linux 서버 코드를 작성한 경험 (15 년 이상)에서 개인적으로 부스트 / ACE가 불필요하게 부풀어 오르고 그들이주는 작은 이점에 대해 유지 관리 위험 (또는 "dll 지옥"이라고도 함)을 도입했습니다.
ACE는 또한 끔찍하게 구식 인 것처럼 보이며 90 년대에 "c 프로그래머"가 작성한 "c ++ 라이브러리"이며 제 생각에는 실제로 보여줍니다. 바로 지금 저는 Pico로 작성된 프로젝트를 재 설계하고 있습니다. ACE 아이디어를 완전히 따르는 것 같지만 더 현대적인 측면에서는 그다지 좋지 않습니다.
고성능, 효율적이고 우아한 서버 통신을 위해 어떤 경우에도 사용하지 않는 것이 좋습니다.