STLAlgorithmExtensions
Dear all, I have a question for the Boost moderators: there seems to be already an STL extension library for Boost. This is of course great, but why isn't it in production? It seems to me that this one of the basic libraries and serves many common needs, like the copy_if request in the development group. It can almost replace our company private STL extension library except for: transform_if is_unique contains contains_if delete_all delete_if and container variants of STL algorithms (i.e. for_each(vec, fc) instead of for_each(vec.begin(), vec.end(), fc). Especially handy for implicit modifying algorithms like remove etc.) Further more there was in 2002 a discussion about a sorted vector. Didn't make it either, which is unfortunate. Wkr, me
Hi!
If I read the documentation correctly about boost::lexical_cast, for a
convertion between two types to work, the source type must be
OutputStreamable and the target type must be InputStreamable (plus some
other requirements about copying and default construction).
Then, any idea why the following code does not work?
/////////////////////////////////////////////////////////////////////////
#include
François Duranleau wrote:
If I read the documentation correctly about boost::lexical_cast, for a convertion between two types to work, the source type must be OutputStreamable and the target type must be InputStreamable (plus some other requirements about copying and default construction).
The problem with your example was that after you read the first double there was a blank space in the input so you could not read the second double. Something like this will do: istream& operator >> ( istream& in , vec& v ) { for ( int i = 0 ; i < vec::size ; ++ i ) if ((in >> v.data[ i ]) && !in.eof()) in.get(); return in ; } I ran into another little problem while debugging your example so I thought I would mention it. Although the documentation does not explicitly say so you kind of make sense that lexical_cast expects the destination object's operator>> to use the complete output produced by the source object's operator<<. In other words: stream << source stream >> target !!! stream.eof() must be true at this point So if you try (like I did) lexical_cast<vec>("1 2 3") with vec.size = 2 it will fail. Hope this helps, -delfin
On Wed, 15 Mar 2006, Delfin Rojas wrote:
The problem with your example was that after you read the first double there was a blank space in the input so you could not read the second double. Something like this will do:
istream& operator >> ( istream& in , vec& v ) { for ( int i = 0 ; i < vec::size ; ++ i ) if ((in >> v.data[ i ]) && !in.eof()) in.get(); return in ; }
As far as I know, when using operator>> on numbers (or any types supported
by the standard library), preceding spaces are skept, unless explicitly
told not to. Mm, after peeking a little more deeply in
I ran into another little problem while debugging your example so I thought I would mention it. Although the documentation does not explicitly say so you kind of make sense that lexical_cast expects the destination object's operator>> to use the complete output produced by the source object's operator<<. In other words:
stream << source stream >> target !!! stream.eof() must be true at this point
So if you try (like I did) lexical_cast<vec>("1 2 3") with vec.size = 2 it will fail.
I know that. Thanks for your help! -- François Duranleau LIGUM, Université de Montréal "The real source of wealth is correct ideas: workable ideas: that is, negative entropy -- Information." - Robert Anton Wilson, _Prometheus Rising_, 1983
participants (3)
-
Delfin Rojas -
François Duranleau -
gast128