Philippe Vaucher wrote:
lexical_cast was NEVER thread safe to start -- not one word in the docs indicates that it is thread-safe, and the implementation clearly isn't because of several things that are used. So clients using lexical_cast from multiple threads should beware...
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.
It looks like the "thread-dangerosity" you're speaking about is like the same we would have by used two different stringstream objects in two different threads...
Yep.
Enlighten me if I missed something.
Well again, please show me in the lexical_cast documentation the line that indicates that it is a 'thread-safe' operation. You won't find it because it isn't. You have the issues of both the internal implementation and the types being converted to/from (eg: string) using global data in their implementation. Since lexical_cast is generic, it has no way of controlling the thread safety of user defined types and their associated operator>> and operator<<. 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' ;-) Jeff