From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-06-29 05:49:58
In message <005d01bfe124$c319bf60$3e116e97_at_[hidden]>, Ed Brey
>From: "Kevlin Henney" <kevlin_at_[hidden]>
>> (3) On a point of implementation rather than interface, I was wondering
>> about reducing the cost of stringstream creation in single-threaded
>> static std::stringstream stream;
>This is OK only if we make a rule saying that iostream overload
>implementations for user-defined types can't use stream_cast. For example,
>say you have a Point class and an Area class, each of which store two
>integers and read and write them to streams of the form "123,456", but are
>otherwise unrelated. They could be converted with stream_cast. If either
>of them, for whatever reason, would happen to use stream_cast in their
>streaming implementations, you'd run into a reentrancy problem.
Hmm, that might too restrictive, and could be an interesting source of
bugs. Given that, I will leave it with the overhead in the name of
convenience and correctness.
>On a separate sub-thread, Jeffrey Paquette wrote:
>> Why not go with existing practice and write:
>> a = interpret_cast<A>(b, std::nothrow);
>> for the non-throwing version?
>The nothrow version has been suggested before (several times, I think). A
>problem is that there is no way to know whether the conversion succeeded or
>failed. Unlike with a pointer to a new memory allocation, there is no
>special value for a converted type to indicate that the conversion failed.
>The form of the conversion/cast that returns a bool addresses this problem.
I would contend that this leads to three ways of using the cast rather
(1) Use it so that it throws on failure.
(2) Use it so that it does nothing on failure and defaults the value.
(3) Use it so that it returns a status on failure.
I personally would use (1) if I wanted to know about failure and (2) if
I didn't, which makes (3) seem a little like gold plating.
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk