Boost logo

Boost :

Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-04 07:55:33

Hi Ilya,

> Fernando Cacciola wrote:
>> 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 think so. (We have Boost.Serialization for that)
But I had always believe the current semantics were precisely to support

Aparently I've been wrong all along...

Since I never used it I never became familar with it.

>> 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.
> How are you using operator>> with optional<T>? I can't imagine any
> common use case other than lexical_cast.

Simply not using Boost.Serialization but other stuff that nevertheless
relies on IO operators to do a closed roundtrip conversion.

>> 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).
> Btw, the magic space and '--' string is not documented.
Hmmm, that really doesn't look right ;)

>> Why isn't this enough practically speaking rather than theoretically?
> The current semantics is useless for me.
Use case counted :)


Fernando Cacciola
SciSoft Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at