Re: [Boost-users] type_with_alignment

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2006-06-14 22:00:22

On Jun 14, 2006, at 5:04 PM, Gottlob Frege wrote:

> Actually, after thinking about it a bit, I'm now tempted to say a 5  
> byte buffer should have 1 byte alignment.
> eg (given a typical platform):
>
> struct test_alignment
> {
>    int x;
>    char y;
> };
>
<snip>
> So,
> If sizeof(test_alignment) == 5, then the alignment must really be 1  
> (ie there is probably a pragma pack(1) in play).

Sure.  Another way of stating it is that if alignment of  
test_alignment is 1, sizeof must be 5.  However if the alignment of  
test_alignment is 4, then its sizeof must be 8 (on a typical desktop  
platform).  On my system sizeof(test_alignment) is 8.

The alignment and sizeof test_alignment is what it is for a given  
platform, and neither the standard nor the type_traits lib is going  
to change that.  What the type_traits lib can do is help report those  
facts.

> Also, in any case, for boost::type_with_alignment<5> doesn't  
> compile.  I think it should at least do something (or else the  
> standard/docs need to have lots of wording explaining which ints  
> work and which do not).
>
> Similarly, aligned_storage has the same 'problem' and basically  
> only works with alignment_of (or something that does the same thing).

I think failing to compile is exactly what should happen for  
unsupported alignments.  Requesting an unsupported alignment is an  
error, and finding out at compile time is a feature, not a bug.

>   Since that is the case anyhow, I would suggest that  
> aligned_storage be replaced with:
>
> storage_for<T, count = 1>;
>
> (which can be written in terms of aligned_storage and alignment_of,  
> but since the two are tied together, and typically used together,  
> why not just supply what is really wanted).
>
> So really I'd like:
>
>    storage_for_type<T, size_t count = 1>
> and
>    storage_for_size<size_t>
>
> where storage_for_size determines the minimum necessary alignment  
> based on the size, as discussed.

<shrug> storage_for_type<T, size_t> is a nice convenience function,  
and I can't get too worked up over it myself either for or against.   
Like you say, it can (easily) be written in terms of aligned_storage  
and alignment_of.  In general I'm strongly in favor of a fundamental  
interface.  Convenience functions built on top of the fundamental  
interface don't excite me very much either pro or con.  Though  
std::basic_string did carry the convenience interface a little too  
far imho.  Note that there are things you can do with aligned_storage  
that you can't do with storage_for_type (making it more  
fundamental).  For example:

aligned_storage<4096, 4096>::type page_buffer;

No, it isn't portable.  But it sure is valuable to be able to use  
this when you know you can (and yes, I'm on a platform where I can  
use 4096 byte alignment, and where it has uses).  And if the code  
accidently gets ported to some place where it isn't supported, you  
find out at compile time (asap).

-Howard