----- Original Message ----- From: "Rozental, Gennadiy" <[EMAIL PROTECTED]> To: "'Boost mailing list'" <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost