Re: [boost] Plea for addition of stream_cast

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-06-28 10:14:52

In message <4.3.2.7.2.20000627075426.025af8b8_at_[hidden]>, Beman
Dawes <beman_at_[hidden]> writes
>I would like to move ahead with two versions of Kevlin's stream_cast 
>concept.  One which throws on errors as suggested by Steve Cleary, and one 
>reports errors via bool return as suggested by Ed Brey.  I modified Ed's 
>code so it default initializes per Kevlin's code. The intent is that the 
>two argument form can be used without checking the error return when 
>default behavior on errors is desired.

Sorry for the recent radio silence. Been a little busy, but still had
the chance to play around with the stream_cast idea a bit, although I
missed some of the discussion.

I have come round to thinking that the default version of stream_cast
should be throwing, and the other variant should be default
initialising. IIRC, this was pretty much the mood of the group.

>It seems to me these are really conversion functions, and have named them 
>as such.

Not sure I get the point: as functions intended to be used in a cast-
like manner, I think that covers the "conversion functions".

However, in terms of naming and syntax, I have been having some other
thoughts:

(1) I originally named the cast interpret_cast, and after some
discussion with Beman and Greg, IIRC, changed it to stream_cast.
However, I am drawn back to interpret_cast as this seems not only to
capture the spirit (if not the mechanism), but also allows some
latitude, namely the use of specialisation to optimise certain cases, eg
to use strtol for const char * -> long or string -> long. What do others
think of (a) the name, and (b) offering some optimised cases?

(2) For distinguishing between throwing and nonthrowing versions, I
tried out a few syntax forms, and found the following style one of most
convenient and "in the spirit":

        a = interpret_cast<A>(b);
        a = interpret_cast<A>(nonthrowing(b));

Whichever way we go, I would prefer to keep both forms as cast-like as
possible. Feelings on this?

(3) On a point of implementation rather than interface, I was wondering
about reducing the cost of stringstream creation in single-threaded
apps. So rather than:

        std::stringstream interpreter;
        ...
        interpreter >> result;

A wrapper could be used:

        stream_wrapper interpreter;
        ...
        interpreter.stream >> result;

Where the wrapper would look something like:

        struct stream_wrapper
        {
                #ifdef BOOST_MULTITHREADED
                std::stringstream stream;
                stream_wrapper() {...} // reset stream
                #else
                static std::stringstream stream;
                #endif
        };

Thoughts?

(4) On the issue of specifying precision for certain conversions, I had
wondered about some kind of traits class. However, most of the
implementations I have come up with seem to be more convoluted than is
worth the effort given the problem of convenience the cast is supposed
to solve. Ie it is easier to specify one's intent precisely and more
succinctly using raw stringstreams than trying to overgeneralise the
basic cast. What do others think?

>What header should these go in?  They aren't casts; they are more utility 
>in nature.  So how about boost/utility.hpp?

If they are casts, which I would maintain they are, then I guess they go
with the other casts. Maybe it's just me, but I'm always faintly
suspicious of headers/directories/libraries that are called util or
utility: whilst not intrinsically a problem, they can end up as
repositories for almost anything that didn't fit any other
classification!

>In any case, let's try to finish cast and stream_cast/convert issues and 
>put the headers up for formal review.  If Kevlin is still busy, I will pull 
>the details together if we can get general agreement.

Based on feedback as to which way we should go with syntax etc I can
pull this together as I have a test harness for it, and I can update the
previous documentation to reflect the broader scope of the newer
function(s).
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________