Re: Problem with `string', threading and shared libraries.

[Carlo Wood <carlo at alinoe dot com>]

On Fri, Sep 28, 2001 at 06:40:28PM -0300, Alexandre Oliva wrote:
> > If they are really considered to be two different classes, then
> > "std::string" is a truly bad choice.  
> 
> Well, using different compilers can always result in different
> mangling for std::string.  In this case, it's the same version of GCC
> built with different configure arguments, but the configure arguments
> still make them different compilers.

Actually, this was all on my own machine - using one and the same
compiler.   I compiled my library with a #define _NOTHREADS
(because it is not supporting threads), and then got 'undefined
symbols' in test applications that did not define _NOTHREADS
(although they were also not threaded).

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

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.

The only thing that changes anyway, the default allocator.

According to the Standard,

[lib.string.classes] 21.2 String classes

namespace std {
  typedef basic_string<char> string;
}

[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 {
    // ...
    };
}

>From which follows that the standard demands that `std::string' is
equivalent with

basic_string<char, char_traits<char>, allocator<char> >

There is no room for fluctuating `allocator' classes imho.
The use of a string_char_traits<char> is also not complying
to the standard.

Concentrating on the `allocator' template for the moment,
I think that the mangling of the type `allocator<char>' should
be the same for all possible configurations.  A different choice
for the default allocator should be made as a result of
linking - and not be made at compile time of an application:
that is not compatible with shared libraries.

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

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?

-- 
Carlo Wood <carlo@alinoe.com>