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.