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

[Carlo Wood <carlo at alinoe dot com>]

On Fri, Sep 28, 2001 at 06:08:59PM -0300, Alexandre Oliva wrote:
> On Sep 28, 2001, Carlo Wood <carlo@alinoe.com> wrote:
> 
> > I was wondering, how can it be that `string' has a different
> > mangling on different compilers/machines?  Isn't that a bug?
> 
> Well, it can be argued that they are actually two different classes,
> one that is thread safe and uses a certain thread library to
> accomplish this, and the other that isn't.  So, it's reasonable for
> them to have different manglings, especially if you'd like to use both
> of them in the same multi-threaded application, to save the costs of
> synchronization when it's not necessary.

Ok, but that doesn't solve my problem that is the result of this.
In my shared library I define a public class with the following
methods:

  void set_margin(std::string const& s);
  std::string get_margin(void) const;

Suppose I wish to distribute the library in binary form.
Then I can provide two `set_margin' methods, one for a thread-safe
string and one for the unsafe string, but I can't make `get_margin'
return two different types.

I could change every class that uses `string' in it's interface
into a template I suppose (with the current `string' type as
parameter) but that basically means you can't distribute shared
libraries: it would be recompiled every time and included in the
end-application instead of being code in the shared object file.

If I want to try any other solution, then I will need to have
explicitely both types available, which means I can't use just
`string' but will have to use

basic_string<char, string_char_traits<char>, __default_alloc_template<htreads, 0> >

and `__default_alloc_template' is not portable.
Is there a portable way to get the "internal" thread-safe and
non-thread-safe string types?

-- 
Carlo Wood <carlo@alinoe.com>