This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Re: [PATCH] Canonical types (1/3)
On 12/5/06, Paolo Carlini <pcarlini@suse.de> wrote:
Hi Doug,
a quick reply to a couple of specific points of yours.
> Anyway, even with a fix for 19163, you still need to enumerate all of
> the possible alignment values, right?
I don't think so: see my comment in type_traits. Actually, this is the
whole point of my message ;) In my opinion this *should* work:
template<std::size_t _Len, std::size_t _Align>
struct aligned_storage
{ typedef char type[_Len] __attribute__((__aligned__(_Align)));
AFAIK, it works *already* with the Intel compiler :-/
Yes, this should work, although I think the safest definition would be:
template<std::size_t _Len, std::size_t _Align>
struct aligned_storage {
union type {
char __bytes[_Len];
struct __attribute__((__aligned__(_Align))) { } __aligner;
};
};
That way, the user can't accidentally eliminate the alignment
information for "type" by equating it with a normal (no attributes)
array char[_Len].
> If so, then there is a
> workaround for TR1/C++0x aligned_storage. GCC handles alignment
> properly on class types, so Boost uses this little hack to make its
> "type_with_alignment" trait work:
Before going ahead with this part of the discussion: in your opiniuon,
is this solution it substantively better than our *current* implementation?
No, it isn't better than the current implementation.
Cheers,
Doug