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

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-02-07 17:00:04

On Tuesday, February 07, 2012 22:36:56 Hite, Christopher wrote:
> Sorry for not coming back quicker.  I've been sick.
> 
> I did some experimenting in my own codebase with a "array_vector" which acts
> like vector constructs things when they're added, but like boost::array
> uses a fixed size array.
> 
> I tested the techniques I would use to improve optional.  So I think I can
> deliver this very small set of goals cleanly:
> 
> 1) ~optional doesn't set m_initialized.
> 
> 2) has_trivial_destructor<T> implies has_trivial_destructor<optional<T> >
> 
> 3) has_has_trivial_copy<T> and has_trivial_assign<T> implies them optional
>         unless sizeof(T) exceeds some constant max_trivial_copy_Size, which
>         can also be overridden.
> 
> 4) I'll define a optional_traits<T> with defaults and an
>         optional_with_traits<T,Traits=optional_traits<T> >
> which can be used to make optionals which override features and from which
> optional<T> will derive.  That's the best compromise if I can't change
> the signature of optional (Is Robert Stewart right?).  I think we should use
> the traits technique for any new libraries.

Do I understand it correctly that optional_with_traits is an advanced 
replacement for optional? If so, will the good old optional be optimized? I 
think, it is possible to optimize the current optional without changing its 
signature if we specialize optional_detail::optional_base on the types or 
traits we're interested in.

BTW, I would really like to see optional< T& > optimized to store T* 
internally.

> Shall I continue?  Should I make branch or do it in trunk?

I think, a branch or sandbox is a good start.