Re: [boost] [optional_io] InputStreamable refinement

Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2009-03-02 10:48:24

Fernando Cacciola <fernando.cacciola <at> gmail.com> writes:
> [skip]
> 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?
E.g

string in("two words");
stream << in;

string out;
stream >> out;
 
assert( in != out ) ;

> That's not all.. you also need a way to detect an unitialized value. You 
> proposal uses extraction failure for that because it works perfectly 
> fine in the context of lexical_cast since the stream contains 
> exclusively the given optional (possibly empty) and nothing else.

I don't care about lexical_cast here, my implementation is based on
reading Boost.Optional documentation:

[---
optional<T> intends to formalize the notion of initialization (or lack of it)
allowing a program to test whether an object has been initialized and stating
that access to the value of an uninitialized object is undefined behavior.
That is, when a variable is declared as optional<T> and no initial value is
given, the variable is formally uninitialized. A formally uninitialized
optional object has conceptually no value at all and this situation can be
tested at runtime. It is formally undefined behavior to try to access
the value of an uninitialized optional. An uninitialized optional can be
assigned a value, in which case its initialization state changes to
initialized. Furthermore, given the formal treatment of initialization states
in optional objects, it is even possible to reset an optional to uninitialized.
---]

>From "it is formally undefined behavior to try to access the value of an
uninitialized optional" I conclude that it is formally undefined behavior
to output an uninitialized optional.

> [skip]
> I recall very well now having this very same discussion on the distant 
> past. It used to be as you want it, but for the sake of the 
> serialization library I choose the current semantics, precisely because 
> as Robert indicated the serialization library doesn't explicitely depend 
> on Boost.Optional.

Was it during review or after? Do you have a link to this discussion?

Thanks,
Alex