stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
Date Mon, 30 Jun 2008 16:57:38 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> I searched library headers and sources for how we define unions and
>> with the exception of limits_bits.cpp we always follow this rule.
>> Unless there is a reason not to make this change to aligned_union,
>> I think we should change both limits_bits.cpp and aligned_union to
>> always define the member with the more strict alignment requirement
>> first, just for peace of mind.
>> Is there any reason/advantage to having the char buffer first?
> If the first member is used to define the alignment, then you have to
> know (at compile time) which of the union members has the strictest
> alignment requirement so that it can be put first.

Yes. But putting the char buffer first doesn't obviate the
need to do this, does it?

Btw., if you're not subscribed to yet,
aligned_union was among the alignment features discussed
last week. An new issue has been filed to remove
aligned_union because it's superseded by the alignas()
core language feature:

I also plan to submit an issue to remove the other aligned
traits for the same reason, although the initial feedback
suggests that this issue might be more controversial than
the removal of aligned_union.

In any case, it seems likely that the question of which of
the members of aligned_union comes first may soon be moot
anyway. That said...

> This problem comes up in the definition of __rw_aligned_buffer. On most
> implementations the members are ordered according to the scheme you
> mentioned previously, but it is very possible for them to be out of
> order.

...I'm not sure I see your point WRT __rw_aligned_buffer. In
the absence of alignas (or some such), how do you suggest we
prevent this?


>     union {
>         long double _C_pad;
>   #else
>         double      _C_pad;
>   #endif   // _RWSTD_NO_LONG_DOUBLE
>         void       *_C_void_pad;
>         void      (*_C_pfn_pad)();
>         char        _C_data [sizeof (_TypeT)];
>     } _C_buf;
> Travis

View raw message