From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-08 13:24:24
Felipe Magno de Almeida wrote:
> On 9/8/06, Jeff Garland <jeff_at_[hidden]> wrote:
>>> There's something I want to clear out, lexical_cast is reentrant and only
>>> uses "stacked" variables no ?
>> So what? Those stack types are free to reference global data. And in the case
>> of stringstream, in combination with operators<< and operator>>, they most
>> certainly do access global data in the form of locales and facets.
> But I believe almost every STL implementation has thread-safe
> iostreams, with locked access to global locales and etc. I know that
> VC 7.1 and STLPort has. Without it, it is almost impossible to write
> thread correct C++ programs. Or am I missing something?
It's not portable because the standard says nothing about threading or thread
safety in I/O. And as I recall I've seen at least one implementation that
supports compiling out all thread safety, because it is a huge performance hit
to make I/O threadsafe. So, again it may mostly work, but it isn't assured
by anything in the standard. So in the context of lexical_cast, nothing is
>> The real problem here, is that lexical_cast *will work* most of the time in an
>> MT environment without difficulty. But that's not good enough to declare it
>> 'thread-safe'...which is the entire assumption in this thread. Actually, as
>> this whole discussion illustrates, it's probably enough to make it
>> 'thread-dangerous' ;-)
> It is only thread-safe if what it uses has the basic thread-safety
> guarantees. Which, for all I know, it is true in every implementation
> that cares about writing thread-safe programs.
If it were me, I'd guard any use of lexical cast I thought was to be used in
an MT context because it's a time-bomb waiting to fail. I'm sorry to keep
going on about this, but the whole thread that spawned this one had the
embedded presumption that lexical_cast is thread-safe and I wanted to dispel
that myth -- it's obviously deeply entrenched.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk