lexical_cast<> in 1.39 does not provide basic_stringstream to operator>>
Just ran into a regression in old code that last worked [probably] with 1.32 -- I have a number of ADTs which use tellg()/seekg() in their implementations of operator>>. This used to work fine with lexical_cast and now it breaks because the [optimized?] version in 1.39 uses a statically allocated buffer and plain Jane basic_streambuf which does not implement seekpos() and seekoff(). According to http://www.boost.org/doc/libs/1_45_0/libs/conversion/lexical_cast.htm#n1973, operator>> called from a lexical_cast should have at least basic_stringbuf to work with. Now, this project is locked into 1.39 for administrative reasons and I will have to work around the issue anyway. Still, I'm curious whether this is a problem that has been fixed since 1.39, a previously unnoticed bug or a by-design behavior that I am misinterpreting as a violation of spec... Thanks in advance, ...Max...
27.01.2011, 21:33, "Max Motovilov" <max@motovilov.net>:
Now, this project is locked into 1.39 for administrative reasons and I will have to work around the issue anyway. Still, I'm curious whether this is a problem that has been fixed since 1.39
No. You're the first person who brought this up, to my knowledge.
Just ran into a regression in old code that last worked [probably] with 1.32 -- I have a number of ADTs which use tellg()/seekg() in their implementations of operator>>. This used to work fine with lexical_cast and now it breaks because the [optimized?] version in 1.39 uses a statically allocated buffer and plain Jane basic_streambuf which does not implement seekpos() and seekoff(). According to http://www.boost.org/doc/libs/1_45_0/libs/conversion/lexical_cast.htm#n1973, operator>> called from a lexical_cast should have at least basic_stringbuf to work with.
I think it was a recommendation. In the next sentence, they say that implementations are not required to use basic_stringstream. OutputStreamable concept refers to ostream and wostream objects. Which means that if some instantiation of OutputStreamable is unable to use seekpos()/seekoff(), it should use an alternative implementation. -- Alex
Well, be nice to document it that way I guess... after all, the operator>> implementations should not depend on the way lexical_cast<> is implemented so if basic_ostream is all that they can count on, then that should be explicit... Unfortunately there's no concept for seekable stream in the standard library that could be checked at compile time -- or is there now? I have to admit I wasn't following the latest ISO happenings. Regards, ...Max...
27.01.2011, 21:33, "Max Motovilov"<max@motovilov.net>:
Now, this project is locked into 1.39 for administrative reasons and I will have to work around the issue anyway. Still, I'm curious whether this is a problem that has been fixed since 1.39
No. You're the first person who brought this up, to my knowledge.
Just ran into a regression in old code that last worked [probably] with 1.32 -- I have a number of ADTs which use tellg()/seekg() in their implementations of operator>>. This used to work fine with lexical_cast and now it breaks because the [optimized?] version in 1.39 uses a statically allocated buffer and plain Jane basic_streambuf which does not implement seekpos() and seekoff(). According to http://www.boost.org/doc/libs/1_45_0/libs/conversion/lexical_cast.htm#n1973, operator>> called from a lexical_cast should have at least basic_stringbuf to work with.
I think it was a recommendation. In the next sentence, they say that implementations are not required to use basic_stringstream.
OutputStreamable concept refers to ostream and wostream objects. Which means that if some instantiation of OutputStreamable is unable to use seekpos()/seekoff(), it should use an alternative implementation.
participants (2)
-
Alexander Nasonov -
Max Motovilov