|
Boost : |
From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-01-20 07:55:47
Andy,
>Coincidentally, I have been trying to persuade Intel's compiler's to pad
only contextually, violating your first assumption.<
How would that be possible? Surely the standard mandates that sizeof(T) is
a compile time constant for all T, so context sensitive padding is not
really possible.... unless maybe the compiler defined two sizes: a minimum
size and a padded size (for arrays), the latter would be sizeof(T) in all
cases, but in situations like:
struct A{
B b;
char c;
};
the character c could be stored "within" the trailing padding of instance b
(if there is any). Is this what you had in mind? I can imagine that this
would break some existing code, but probably not any code that conformed to
the standard exactly (if there is any such beast :-) ).
Steve:
>template <typename T>
>struct empty_helper_t1 : public T { char i[sizeof(empty_known)]; };
>struct empty_helper_t2 { char i[sizeof(empty_known)]; };
I think that there may be situations when that would give the incorrect
answer:
Imagine that sizeof(empty_known) is one byte and one byte aligned (there's
at least one platform - spark/gcc - that does this, I know this 'cos it bit
me!).
Imagine that sizeof(empty_helper_t2 ) is 4 (ie padded out to alignment).
In this case empty_helper_t1 could place the extra sizeof(T) bytes it needs
within the "padding": not expanding its size in relation to empty_helper_t2
even when T is not empty.
Or then again maybe not :-)
Whatever I think that the assumption that the current version version makes
(that the platform alignment is a power of 2) is reasonable and likely to
work in most cases, but by all means let's experiment with other
implementations and see what breaks on what platforms, whatever we do, its
likely to be susceptible to platform specifics.
However: for compressed pair do we need is_empty at all? If either of the
template parameters are a class, then why not derive from them regardless?
It can't do any harm and it may just do some good.
- John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk