Re: [boost] Plea for addition of stream_cast

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-05-29 08:00:39

From: "Jens Maurer" <jmaurer_at_[hidden]>
> Here are some code snippets, abstracted from the real stuff
> to protect the innocent:

<snip>
So here it looks to me like you're using it as a quick-and-easy substitute
for i/o-stringstream. That's a really important usage to support. When the
people I work with ask me, "how do I convert a string into an int in C++", I
feel really weird telling them, "use an istringstream". There's just too
much mechanism there.

I seem to remember that there were other usage models which didn't involve a
string as either the template parameter or as the argument. But I suppose
that just makes it even more flexible.

So, I think we should move quickly to get stream_cast into the library. I,
too, think that throwing an exception is the more useful default behavior.
Is there any use for the version that fails silently? If there is, I propose
that we use the syntax
   stream_cast<target_type>(source_value, std::no_throw)

I am concerned about one final thing: stream_cast is, I expect, useless with
types that can't be default-constructed. I don't think this is stream_cast's
fault, but rather a fundamental problem of idiom in the standard library.
operator>>() is just the wrong way to stream objects which don't have a
default constructor - those types should be constructible from a stream
parameter. Maybe we need an istream_traits<T> class which describes the way
to produce a T from an istream?

-Dave