+1  A: 

There is always choice that has to be made if you don't want to support everything, but I personnally feel restricting input to UTF-8 is the easiest of all. Just use plain old std::string and everyone's happy. In practice, the user (of your library) will only have to convert to UTF-8 if he's on Windows, but there's a plethora of ways to do that simple task.

UPDATE: on the other hand, you could template all of your code and leave the std::basic_string<T> as a template throughout your code. This only gets messy if you do different things dependent on the size of the template argument.

rubenvb
The first solution can't handle custom traits or allocators. And the second one is totally overkill.
cytrinox
See @Martin's responses, he hits the nail on the head... You can't cater for *every* possible type of string variation, just stick to the standard, no user will care what internal representation you use as far as I can see...
rubenvb
The "problem" is not to specify one internal representation. The problem is the convertion to the internal representation from various basic_strings and basic_streams. How to design/write an interface which accepts both templates with various arguments and convert them internally to the internal representation?
cytrinox
@cytronix: accepting all sorts of strings with all kinds of allocators and traits and byte-sizes is going to be cumbersome and IMHO should be left up to the user of your library.
rubenvb
Okay, how can the user easily do this? Say I define a method that requires a std::wstreambuf* as argument and puts some data into - and the user has a basic_streambuf<wchar_t, char, users_traits> object?
cytrinox