This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

In article <> you write:
>Carlo Wood <> writes:
>| I really think that it was a wrong decision to include
>| thread-safeness in the mangling of std::string.
> So we're at least two then.

When you agree with Carlo on this matter, be sure you fully understand
what you are agreeing to.

He had compiled libstdc++ with a macro, reserved to the
implementation, defined and then he compiled his user code without
that macro defined.  Nowhere do we document that macro being used by
normal users of the library.  

Here is what we say in internal configuration documentation of the
library, libstdc++-v3/include/bits/c++config :

// [...] Note:
// that gthr.h may well map to gthr-single.h which is a correct way to
// express no threads support in gcc.  As a user, do not define
// _NOTHREADS without consideration of the consequences (e.g. it is an
// internal ABI change).

Note that it is explicitly marked as something that will change the
ABI (i.e., you can't link code compiled with and without that macro
defined).  I honestly don't know how much more of a warning is merited
for a symbol outside the normal user-space.

The main reason I did not entirely remove support for that macro was
that it was used in the SGI STL code.

Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]