ICU 또는 부스트 로케일 사용을 고려 중입니다.ICU 대 부스트 로케일 (C++)
각 장단점은 무엇입니까?
나는 ICU를 사용하는 것을 모두 이해하지만 ICU는 부스트 로케일에 의해 숨겨져 있습니다. Boost Locale's rationale page에 따르면 "... 전체 ICU API는 불투명 한 포인터 뒤에 숨겨져 있으며 사용자는 액세스 할 수 없습니다."
이러한 라이브러리를 비교할 때 C++ 11에서 새로운 유니 코드 기능을 고려하십시오.
ICU는 국제화 전문가가 설계했지만 부스트는 C++ 프로그래머가 설계했습니다.
강력하고 우아한 C++이지만 부스트가 많은 국제화를 잘못 만든다. 부스트는 라이브러리의 큰 컬렉션이며, 일부는 다른 라이브러리보다 효과적입니다. 그러나 ICU는 전체적으로 견고하며 마이크로 소프트를 제외한 모든 사람들이 ICU를 기반으로 사용됩니다.
그럼 국제화가 필요하다면 ICU로 가십시오. 최첨단 C++ (그러나 i18n 종류의 흔들림)를 원한다면, 부스트를 시도하십시오.
ICU는 아주 좋은 도서관이지만 단점이 있습니다
참조를 사용하는 이유는, 메시지 번역 도구까지 완벽한에서입니다입니다
Boost.Locale은 C++ 방식으로 현지화하고 또한 ICU 외에도 다른 백엔드를 사용할 수 있습니다 (물론 ICU가 더 우수합니다). Boost.Locale은 많은 경우에 Boost.Locale이보다 간단하고 현대적인 C++ 및 일반적으로 사용하기 쉽습니다.
Boost.Locale 에서 지원하지 않는 매우 정교한 알고리즘이 필요하거나 응용 프로그램에서 유니 코드 처리가 필요한 경우 ICU가 더 좋을 수도 있습니다. Boost.Locale은 C++ 응용 프로그램을 지역화하는 데있어 더 좋습니다.
나는 Boost Locale 인터페이스를 좋아하지만 u_isalpha() 나 u_isalnum()과 같은 다른 ICU 함수에 대한 액세스가 필요하다. 뭔가를 간과하지 않는 한 Boost Locale을 통해 액세스 할 수 없다고 생각한다. 그렇지 않다면 Boost Locale에 해당 함수를 래핑 할 계획입니까? –
Boost.Locale은 ICU를 기본 백엔드로 사용합니다. Boost.Locale도 일부 other backends을 사용할 수 있습니다. Boost.Locale은 ICU와의 더 나은 인터페이스라고 생각할 수 있습니다.
아주 좋은 요약, 확실히 +1. "매우 불안정한"국제화는 매우 간단하고 기본적인 것들만 필요하다면 괜찮을 수도 있습니다. 모든 애플리케이션에 ICU와 같은 기능이 필요하지는 않습니다. 그리고 ICU의 C++ API는 현대적인 C++/Boost 스타일에 익숙하다면 상당히 고통 스럽습니다. – jalf
-1. OP는 ICU와 * Boost.locale * 사이의 비교를 원합니다. Boost.locale은 ICU와 GNUGettext를 감싸는 라이브러리입니다. "Boost.locale은 많은 국제화를 가져옵니다. [...] 부스트는 라이브러리의 큰 컬렉션이며, 다른 것들보다 나은 것들도 있습니다. ICU를 직접 사용하는 것이 낫지 않겠습니까? –
답변은 묵시적입니다. ICU를 직접적으로 사용합니다 .Boost.locale은 래퍼이므로 ICU 또는 그보다 더 좋을 수 있습니다. ICU보다 C++이 더 좋아 보이지만 추가 버그가 발생할 수도 있습니다 (Mac OS X API 포장 ICU에서 ICU에없는 버그가 도입 된 상황을 알고 있습니다). 또한 Boost.locale은 UTF-8을 계속 사용합니다.ICU는 UTF-16에서 작동하기 때문에 모든 호출이 UTF-8에서 UTF-16으로 변환 및 뒤로 이동해야하며, 문자열 스트링 등을 매핑해야합니다. 성능이 저하되고 오류가 발생하기 쉽습니다. –