Felipe Magno de Almeida wrote:
On 9/8/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
[snipped]
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 assured...
[snipped]
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. Jeff