I've been reviewing this library, and wow, it is brilliant. The APIs provide excellent functionality with a sensible and modern design. Congratulations, this is very well done.

The only problem for me is the lack of support for wide characters, and unfortunately, it's a deal breaker. My app deals in wide characters, and I can't take on the cost of constantly converting my strings between w and a. I've read the rationale for this, and there must be something missing because I just don't understand it. Boost, which is otherwise inferior to POCO as far as I'm concerned, has wstring support. Why can't POCO?

millisecond wrote:I've read the rationale for this, and there must be something missing because I just don't understand it. Boost, which is otherwise inferior to POCO as far as I'm concerned, has wstring support. Why can't POCO?

UTF-8 was chosen because it is platform independent and all POCO interfaces can operate with std::string. If you present a case on how to use wide chars in a platform-independent way other than what we do now, we may consider it.

Given the principal brokenness of wchar_t/std::wstring (especially on non-Windows platforms), and the amount of effort that would be required to make POCO support std::wstring in addition to std::string, I don't see that happening.

C++0x will contain better support for Unicode (char16_t and char32_t and corresponding strings), so there's some hope...

On the other hand, I don't see much of a problem in converting strings between UTF-16 and UTF-8. You'll have to do that anyway in most typical POCO uses (e.g., creating UTF-8 encoded XML files, sending UTF-8 text over the network, accessing databases, etc.) and Poco::UnicodeConverter provides a convenient interface for doing that.

Well I do see a lot of problems. Especially with the performance. Having an application using UTF-16 strings internally and using a POCO in it, it just a nightmare. It starts with arguments processing, then the Path, URI, and other good stuff. All the parameters have to be converted between these two. I'm currently working on a Google's V8 integration and was really happy when I found Poco, as it offers everything I need. V8 uses UTF-16 inside and defines it's internal strings using uint16_t*, which easily converts to Windows' wchar_t*. Having a uint16_t (or that char16_t from the future) on Poco side would be perfect, as Windows users won't have to worry too much.

Offering a conversion is not what I would expect from a general-purpose library (!) like Poco tends to be.

POCO is, as you should have expected, multi-platform. Why should the scarce developing time be used for something that would not work on all platforms, especially if it's to favor Windows ?

You are actually asking for something that's not of genral purpose, and it seems you're planning on having your app run only on Windows.Then either help POCO by adding what you want to it, or deal with the current situation.