From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-08-01 05:59:31
>This also screens out any empty UDTs that are convertible to int -- a
>ridiculous situation, but it should be doc'ed, IMO.
Yes I know, that's why I haven't used it for is_enum. Actually I can't
really imagine an empty class that could usefully be converted to int, but
as you say I'll document it.
>Sorry! I'll try to be gentle this time: it's still not guaranteed to
>;) However, I think it is good enough -- it would work for all "normal"
>compilers (all I know of).
>The compiler can also add padding to the end of its struct, although in
>implementation I cannot imagine a compiler wanting to do so (since T is
Yes, the compiler can add as much extraneous padding as it wants, however
as I said the result must always be a multiple of the actual alignment (but
not necessarily a multiple of 1). The reasoning follows what happens if
you have an array of alignment_of<T>::padded, the address of each
sub-object of type T in the array is given by:
base + offsetof(padded::t) + n*sizeof(padded)
In order for each sub-object in the array to be aligned it is necessary
that both offsetof(padded::t) be a multiple of T's alignment, and for
n*sizeof(padded) to be a multiple of the correct alignment for all n.
From this it follows that sizeof(padded) is a multiple of the alignment of
Further, sizeof(padded)>sizeof(T), for all T, so:
sizeof(padded) - sizeof(T) == k1*Align(T) - k2*Align(T) : for some integers
k1, and k2 with k1 > k2.
hence sizeof(padded) - sizeof(T) == (k1-k2) * Align(T) : with k1-k2 >= 1
I hope this makes some kind of sence, formal maths isn't my strong point
(in case you hadn't noticed!).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk