[boost] Re: Re: optional<>: size optimization

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-04-21 07:04:51

Joel de Guzman <djowel_at_[hidden]> wrote in message
news:132a01c307c4$53cd6520$0100a8c0_at_kim...
> David B. Held wrote:
> > "Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
> > news:b7v4u4$8vn$1_at_main.gmane.org...
> >> [...]
> >> I think I like this enhanced version.
> >> 'max_size_type_that_fit_in_padding'
> >> must better be one of the intergral types
> >> to make easy and safe to use, so I guess that
> >> there might ocurr that some bits
> >> are wasted anyway.
> >
> > Why couldn't it be a char[]?
>
> char[] makes sense. Add a tag_size constant int and we're
> in business :-)
>
The reason why I discarded an array (or my problem with it, maybe)
is that it is difficult to get/set it because of
its semantics (array are not first class objects).

Furthermore, suppose there is no padding in a particular
implementation, how is the user supposed to allocate
the tag?
Of course, he can allocate it in its own structure, but he'll
need some awkward metaprogramming in such a case because
the tag will be either in the aligned_storage or somewhere
else.

I think that an usable solution, which might not exploit the
padding 100%, but which will be quite easy to use is this:

template<class T, class tag_t>
struct aligned_storage
{
  void const* address() const ;
  void*       address();

  // If tag_t fits in the padding, it is allocated there,
  // else it is allocated separately (but in here)
  tag_t const& tag() const ;
  tag_t&       tag();
}

Fernando Cacciola