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?)