This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Problem with `string', threading and shared libraries.
- To: Carlo Wood <carlo at alinoe dot com>
- Subject: Re: Problem with `string', threading and shared libraries.
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Fri, 28 Sep 2001 23:28:54 -0700 (PDT)
- cc: libstdc++ at gcc dot gnu dot org, Gabriel Dos Reis <gdr at codesourcery dot com>, gcc-bugs at gcc dot gnu dot org
> 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