This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]