The std::basic_string is tantalizingly general, in that it is parameterized on the type of the characters which it holds. In theory, you could whip up a Unicode character class and instantiate std::basic_string<my_unicode_char>, or assuming that integers are wider than characters on your platform, maybe just declare variables of type std::basic_string<int>.

That's the theory. Remember however that basic_string has additional type parameters, which take default arguments based on the character type (called CharT here):

      template <typename CharT,
                typename Traits = char_traits<CharT>,
                typename Alloc = allocator<CharT> >
      class basic_string { .... };

Now, allocator<CharT> will probably Do The Right Thing by default, unless you need to implement your own allocator for your characters.

But char_traits takes more work. The char_traits template is declared but not defined. That means there is only

      template <typename CharT>
        struct char_traits
        {
            static void foo (type1 x, type2 y);
            ...
        };

and functions such as char_traits<CharT>::foo() are not actually defined anywhere for the general case. The C++ standard permits this, because writing such a definition to fit all possible CharT's cannot be done.

The C++ standard also requires that char_traits be specialized for instantiations of char and wchar_t, and it is these template specializations that permit entities like basic_string<char,char_traits<char>> to work.

If you want to use character types other than char and wchar_t, such as unsigned char and int, you will need suitable specializations for them. For a time, in earlier versions of GCC, there was a mostly-correct implementation that let programmers be lazy but it broke under many situations, so it was removed. GCC 3.4 introduced a new implementation that mostly works and can be specialized even for int and other built-in types.

If you want to use your own special character class, then you have a lot of work to do, especially if you with to use i18n features (facets require traits information but don't have a traits argument).

Another example of how to specialize char_traits was given on the mailing list and at a later date was put into the file include/ext/pod_char_traits.h. We agree that the way it's used with basic_string (scroll down to main()) doesn't look nice, but that's because the nice-looking first attempt turned out to not be conforming C++, due to the rule that CharT must be a POD. (See how tricky this is?)