[boost] Re: stream_cast

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 2000-01-04 08:11:05

>I think this is a great idea!  I don't know about anyone else, but I could
certainly use it!

I recommend we add it to boost.  There is only one change I would like --
it would be nice in some cases to have stream_cast throw an exception
instead of returning T().  Taking an example from the documentation,
stream_cast is used to translate the command-line parameters to shorts; but
if one of them is not translatable, short() is returned, which holds an
unspecified yet valid value.  If an exception was thrown instead, we would
be able to know if the parameters were all valid shorts or not.  Maybe we
could add another
function - stream_cast_throw?<

One of the aims of the stream_cast (née interpret_cast) was to add some
script-like convenience to conversions. As with most scripting languages,
the idea is that stream_cast 'fails softly' returning a reasonable value
(ie the default for the type).

I'm not too keen on adding another variant of the cast as it just leads to
a confusing proliferation of casts, each with slightly different semantics.
However, I think that this behaviour is something that could be catered for
in the proposed traits future directions: a failure value or mode, with the
default being fail soft.

>Another possible addition: (not just for stream_cast but all other kinds
of casts): stream_cast_t<Target, Source> which is a unary function object.
Has this been discussed yet?<

Funny you should say that... :-) When I was playing around with this the
same thought crossed my mind. I think that stream_cast suggests this route
quite strongly, eg the conversion of many args in a sequence. There are two
basic approaches that I can see for this:

   /1/ Provide a corresponding function object for each cast type,
   including the built-in keyword casts.
   /2/ Use a function adaptor, and deal with the built-in casts as special
   cases, perhaps as /1/.

Kevlin