Boost logo

Boost :

From: Gregory Dai (gregory.dai_at_[hidden])
Date: 2006-08-31 21:33:39

On 8/31/06, John Maddock <john_at_[hidden]> wrote:
> Caleb Epstein wrote:
> > On 8/31/06, John Maddock <john_at_[hidden]> wrote:
> >
> >> In any case all the implementations I'm aware of are minimally
> >> thread safe these days, if that's not the case I'd certainly like to
> >> hear about it. BTW implementations that used copy-on-write in the
> >> early days almost all (all?) switched away from that precisely
> >> because of threading issues.
> >
> > Even the latest libstdc++ (GNU's Standard C++ library) uses a
> > refcounted std::string.
> Darn, I hadn't realised that :-(
> > One needs to be careful when sharing strings across thread boundaries.
> > See these bug reports for a detailed discussion:
> >
> >
> >
> Very interesting stuff!
> I'm not sure that it's relevent in this case though: if you're
> lexical_cast'ing *to* a string then these issues shouldn't arise, whether
> there are other threads getting involved or not. If you're casting *from*
> a
> string, then it appears that you need a mutex if you know the string is
> likely to be visible to other threads, even if all accesses to it are
> non-mutating.
> Have I got that right?

Well, not completely perhaps. E.g., at least if the target is a std::string
of size=0, the resultant std::string may well be reference-counted and
shared by multiple threads.

WRT std::string, the solution appears to be using a string implementation
that does not use reference counting, as you rightly pointed out. The GCC
folks can resolve the bugs reported against the GCC library by replacing
their std::string implementation.

In most cases, as we can use std::string w/o worrying about threading
issues, we can do the same with lexical_cast as well.

BTW, I like lexical_cast a lot! Thanks to this community for making it

Thanks, John.
> _______________________________________________
> Unsubscribe & other changes:


Boost list run by bdawes at, gregod at, cpdaniel at, john at