Boost logo

Boost :

From: Matus Chochlik (chochlik_at_[hidden])
Date: 2008-04-03 04:12:58


Cheers,

On Wed, Apr 2, 2008 at 6:19 PM, Jeremy Pack <rostovpack_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk