Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-03 09:02:39
> Fernando Cacciola <fernando.cacciola <at> gmail.com> writes:
>> That is, the current optional_io.hpp is explicitely not designed to
>> support your use case. Instead, it is designed to support the following
>> use case:
>> optional<T> in = -value_or_empty-
>> stream << in ;
>> optional<T> out ;
>> stream >> out ;
>> assert( in == out ) ;
> How can you guarantee this if not all underlying types guarantees this?
I can't of course, and I wouldn't even try. For instance, your
counter-example fails with both the current and your proposed
Or are you saying that, since supporting such a requirement is not
entirely possible since in the end is up to T, it isn't worth doing the
best optional<T> itself can?
> I don't care about lexical_cast here
OK, but you two clearly care for extracting an optional<T> from a stream
that was insterted a bare T instead of an optional<T>.
The current implementation is just not intended to support that.
> my implementation is based on
> reading Boost.Optional documentation:
This is once again the now classic dicotomy between optional<T> as a
super T or as a singleton container of T. This always raise endless
discussions simply because both views are reasonable.
>> on Boost.Optional.
> Was it during review or after?
Long way after the review of Optional, when lots of people started using it.
>Do you have a link to this discussion?
Not that I can find real quick.
I personally never ever needed to extract an optional<T> where a bare T
(instead of an optional<T>) was inserted, so the current semantics just
worked for me.
So, let me step back a bit...
Why do you (Andrew and you Alexander) need this?
With the current implementation you can certainly correctly extract the
correct output provided the stream was inserted an optional<T>, subject
of course to the details of T (as exposed in your counter-example). Why
isn't this enough practically speaking rather than theoretically?
-- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk