From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-06-05 10:25:11
From: David Abrahams [mailto:abrahams_at_[hidden]]
>
> 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.
Agreed
> 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)
A silent failure seems useless. I'd like to see some arguments in favour.
But if it is included, I like the no_throw syntax you suggest.
>
> 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.
I don't see this as a major issue.
> 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?
That may well not be a bad idea in itself, but let's try to avoid getting
bogged down in redesign again.
I propose
1. Accept the exception-throwing version as is.
2. Review the need for a no-throw version, and add it later if needed.
3. Consider istream_traits as a separate issue. If it's implemented, revisit
stream_cast with a view to changing the implementation (but not the
interface) to use it. Until then, just accept the limitation on default
constructible types only.
Paul.