Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David B. Held wrote:
> > "Fernando Cacciola" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> [...]
> >> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
