Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Hite, Christopher (Christopher.Hite_at_[hidden])
Date: 2012-02-08 13:05:26

On Tuesday, February 07, 2012 17:00:04 Andrey Semashev wrote:
> Do I understand it correctly that optional_with_traits is an advanced
> replacement for optional? If so, will the good old optional be optimized?
No, optional will be ("isA") optional_with_traits.  It's just a work around.
I'd prefer to redefine optional:
        template<typename T, typename Traits=optional_traits<T> >
        class optional;

That might in rare cases it could break user code like:
        mpl::quote1<optional>

Personaly I doubt that this is such an issue, but have the best of both
worlds I can define a temporary "optional_with_traits" which when boost
goes to 2.0 we could deprecate and add the parameter to optional.
        template<typename T, typename Traits=optional_traits<T> >
        class optional_with_traits;

        template<typename T>
        class optional : public optional_with_traits<T>  {...};

Do we gurantee boost users that templates will never add default parameters?

> BTW, I would really like to see optional< T& > optimized to store T*
> internally.
I'm going to say something provacative here. I agree with Lucanus.  I see no
reason for optional<T&>.  As far I can tell you could use a T*.  The only
justification I can think of is on system without memory protection you can
build checks into operator*().

Maybe if you're mixing code with old libraries where T* might imply ownership
you might use optional<T&> to imply no ownership and some temporary validity.

Perhaps we should define a new "smart pointer" called dumb_ptr<T> which can't
be assigned into auto_ptr,unique_ptr,shared_ptr, or any pointer type which
implies ownership.

Maybe I'm missing something, but I don't see the justification.

Chris