Re: [boost] Formal review: Optional library

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-11 10:46:12

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

>>
>> There's no need to store p. You can just use
>> static_cast<T*>(buffer.address())
>>
> Yes.. I just shown the pointer explicitely.
> The result of the static_cast<> is a pointer, so to obtain a reference (for
> the operator*) you need to 'actually' dereference this poiner.

I have no idea what you're trying to say here.  Could you try again?

>> > OTOH, when T is a POD, so there is no need to bypass its ctor
>> > (since it has a trivial ctor),
>> > the implementation goes like this:
>> >
>> > template<class T>
>> > class optional2
>> > {
>> >   optional2 ( T const& val ) v(val) {}
>> >
>> >   T const& operator *() { return val; } // No Dereference here
>> >
>> >   T val ;
>> > } ;
>> >
>> > Anyway, if yoy know how to make an efficient implementation like
>> > the second one with an aligned storage I'll be happy to use it.
>>
>> Why do you think that will be any more efficient than the other
>> implementation when T is POD?
>>
> For POD types: operator*() "directly" returns the value.
> The key is that for POD types, since optional wraps just T (unlike any
> variant) and nothing else, aligned_storage is not required.
> optional<> simply contains a data member of type T, that's all.

Why do you think aligned_storage<T> will be any less-efficient than T
when T is a POD?

> If you still don't see it I can show you the typical machine
> generated code for both implementations for operator*().

I'm not surprised the non-POD version is slower as long as you're
storing a separate pointer. If you use the static_cast form I show
above, there's no reason for it to be any worse, AFAICT.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution