Cheers, On Wed, Apr 2, 2008 at 6:19 PM, Jeremy Pack <rostovpack@gmail.com> wrote:
Boris, const char* was just used for consistency with some of the standard library functions that expect const char*. I'm fine changing it though. I have no strong preference either way.
Jeremy
IMHO one way how to solve this is by adding optional support for both char/wchar_t and ::std::string/::std::wstring and allowing to choose one of them based on a definition of some preprocessor symbol at compile time. This would require having a common header file like this and some amout of discipline ;) (using only the new defined types and function proxies) (boost/some-great-header-filename.hpp) namespace boost { ... #ifdef BOOST_USE_WIDE_CHARS typedef wchar_t boost_char; //or bchar ;) typedef ::std::wstring bstring; #else typedef char boost_char; //or bchar ;) typedef ::std::string bstring; #endif // Now for the string-related routines do this: inline int bstrlen(const boost_char* str) { #ifdef BOOST_USE_WIDE_CHARS return ::std::wcslen(str); #else return ::std::strlen(str); #endif } inline int bstrcmp(const boost_char* str) { #ifdef BOOST_USE_WIDE_CHARS return ::std::wcscmp(first, second); #else return ::std::strcmp(first, second); #endif } // etc. } // namespace boost I use this approach in my projects and even with quite complex applications the matter of switching between ASCII/UNICODE is usually simply solved by defining/not-defining a preprocessor symbol. Anyway, this saved me a lot of trouble when we were moving to UTF with our databases and database applications recently. I'm aware that this would require tremendous amount of work, but having library-wide support for this in boost would be great for many people working with non-ASCII strings and IMHO some day soon this will become a necessity anyway, since UTF is (slowly) becoming a standard. best -- ________________ ::matus_chochlik