Problem with `string', threading and shared libraries.

[Benjamin Kosnik]

> My problem here is that std::string changes as a result of a macro
> that is defined or not.

Right.

> Imho, the optimal case would be where std::string is always one and
> the same _type_.  It being thread-safe or not does not have to be
> reflected in the type (mangling), nor does using a different
> allocator for the _default_ std::string.

Right.

> [lib.basic.string] 21.3 Template class basic_string
> 
> namespace std {
>   template<class charT, class traits = char_traits<charT>, class Allocator = allocator<charT> >
>     class basic_string {
>     // ...
>     };
> }

Right.

> There is no room for fluctuating `allocator' classes imho.

Right.

> Of course, this can only be true for the two truely default
> allocators: allocator<char> and allocator<wchar_t>.

Right. The template parameter for allocator has a default.
 
> I'd like to propose to define a template with the name `allocator',
> make a specialization for allocator<char> and allocator<wchar_t>
> and implement their methods with whatever is the default allocation
> model of the compilers configuration.  Then this default alloc
> model is determined during the final linkage, and by the machine
> where the final application runs.
> 
> Does anyone see a problem with this solution?

No. Please add a test case entry as well.

-benjamin