早先對於 Unicode Library 都一直是認為使用 ICU 這個 Unicode Library 來撰寫 Unicode 的程式,但是在 Martinho Fernandes 的 Blog 中寫道:How I want to use Unicode in C++,他開發了 ogonek 這個 Unicode Library,對於 ogonek wiki 所描述 ICU 的幾種問題,引述如下:
ICU offers both Java and C++ interfaces. However, the C++ interface is a direct translation of the Java interface without accounting for the interesting features of the C++ language. This makes ICU very awkward to use in C++, due to the great disparity between the two languages.
Among other things, ICU suffers from the following problems.
在他的 Blog 中也有一些關於 C++11 的文件可以參考。
ICU offers both Java and C++ interfaces. However, the C++ interface is a direct translation of the Java interface without accounting for the interesting features of the C++ language. This makes ICU very awkward to use in C++, due to the great disparity between the two languages.
Among other things, ICU suffers from the following problems.
-
ICU uses dynamic dispatch and runtime polymorphism practically
everywhere. That makes the use of automatic storage duration impossible,
and prohibits normal copy semantics. This could be alleviated by using a
smart pointer all over.
-
The library doesn't use C++ exceptions, and instead takes error code parameters by reference.
-
UnicodeString
is too lenient with error conditions: out-of-bounds indices are adjusted to the nearest boundary; it treats null pointers as empty strings; instead of throwing exceptions, objects set themselves to a "bogus" value when errors occur.
-
UnicodeString
is just a glorified container of UTF-16 code units. Unicode text is not made of code units, but of codepoints. The underlying encoding should not take part on the main interface. Additionally, some developers prefer to store text in UTF-8. ICU's UnicodeString takes that choice away.
-
ICU's break iterators are not C++ iterators, making them unusable with standard algorithms or the new range-based for loop.
在他的 Blog 中也有一些關於 C++11 的文件可以參考。
留言
張貼留言