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.