On Thu, Oct 29, 2009 at 11:28 AM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Wed, Oct 28, 2009 at 11:44 PM, Tan, Tom (Shanghai) <TTan@husky.ca> wrote:
Please have a look and let me know what you think could be improved. The first thing I notice is that it does not support std::wstring directly. It's a big problem in my case I use wide-character in all my applications, which simplifies dealing with UTF-16 adopted by Modern Windows platforms.
If I need to any string info from my program, I'll have to convert from UTF16(represented as std::wstring) to UTF8 so that it could be working well with LOGLITE. That's inconvenient.
OTOH, if you are targeting any other platform in addition to Windows, it probably makes more sense to adopt UTF-8 throughout your program and convert to UTF-16 before calling Windows functions.
Offtopic, I am expecting boost::filesystem V3 for this very same reason.
Way offtopic, I also find path/wpath problematic. In my mind, their invariant doesn't differ enough from that of string/wstring to justify coupling my interfaces with boost::filesystem. So I use UTF-8 string/char const * in my code on all platforms, and use boost::filesystem as an implementation detail, through wrappers that take UTF-8 strings.
I've always found it was easiest to do something like: namespace boost { namespace filesystem { #if defined(_WIN32) || defined(WIN64) typedef wpath npath; #else typedef path npath; #endif } } and then use boost::filesystem::npath everywhere. Performance isn't generally the bottleneck when dealing with the filesystem, but why even bother with so many behind-the-scenes conversions when you can just as easily store everything in the type the O/S is expecting in the first place with a simple typedef? If there's a network layer involved where one platform might have to deal with paths that originated from another platform, then use UTF-8 as the network format, and write a template that converts to npath that is specialized to a nop on non-windows platforms.