Re: [boost] Re: Re: Formal Review Request: class optional<>

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-25 16:58:44

----- Original Message -----
From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
To: "'Boost mailing list'" <boost_at_[hidden]>
Sent: Monday, November 25, 2002 4:25 PM
Subject: RE: [boost] Re: Re: Formal Review Request: class optional<>

> > Your are asking why can't the constructor be not explicit, right?
> >
> > Well, this would allow the 'direct' syntax fn(1,3) that
> > Vincent wanted,
> > but...
> >
> > It would entirely break the pointer semantics because the
> > following would be
> > allowed:
> >
> > void foo()
> > {
> >    optional<int> opt ;
> >    opt = 3 ;  // This will construct a temporary optional<int>(3)
> >    if ( opt == 0 ) // tmp optional<int>(0) here.
> > }
>
> You may poison undesired operators.
>
Yes, I could, but I'm still unconvinced that we need non-explicit optional<>
constructions.
See my response to Vincent.

> > Even if it would be allowed to have optional<int&>, you would
> > still have to
> > use it as if it were a pointer:
> >
> > void foo ( optional<int&> p = optional<int&>() )
> > {
> >   if ( !!p ) // or ( peek(p) ) or ( initialized(p) )
>
> BTW why do you need 3 methods that doing the same?
>
They are not 3 methods to do the same, they just happen to have the same
effect in this particular expressions.

> >   {
> >      int& the_p = *p ;
> >      the_p = 3 ;
> >      etc...
> >   }
> > }
>
> Here 2 questions:
>
> 1. Let say we have
>
> struct A { void moo() { ... } };
>
> a. void foo( A* a ) { a->moo(); }
> b. void foo( A& a ) { a.moo(); } // here we could assume inlining
>
> Does both above versions are equaivalent form assembler stand point?
>
AFAIK the machine code should be *exactly* the same.
>From the code-generation POV, references are pointers with value-semantics.
If it were not as such, references wouldn't have aliasing issues (the 'a' as
seen inside foo is *directly* the same object being passed by the caller).

> 2. Now let say we use optional:
>
> void foo( optional<A&> a ) { (*a).moo(); }
>
> >From assembler stand point will it be equivalent to 1.a or 1.b?
I believe it would be equivalent to both (since 1.a and 1.b are equivalent).

>
> And here yet another example where optional<T&> would be useful:
>
> Let say I am using ostream wrapper for my printing and want to separate
the
> case whgen ostream& is not supplied:
>
> class Log
> {
> ....
>     optional<ostream&> m_output;
> {
>
> And use it for example like this:
>
> template<typename T>
> Log::operator<<( T const& t )
> {
>     if( !!m_output )
>      *m_output << t;
> }
>
> Would it be equivalent to reference or pointer? Or it the same in both
> cases?
>
It's the same in both cases.

Anyway,  optional<> is designed to encapsulate 'objects', and references are
not objects (in the usual sense).

For instance, 8.3.2 says that references are not required to have 'storage'
and you cannot have a pointer to a reference (since a reference might not
have an address itself). (for example, the compiler can use the address of
the object referenced directly without storing this address in memory)
optional<T> wraps a value and so clearly needs to 'store' it inside; it just
cannot allow its parameter to be a reference because of the above.

Fernando Cacciola