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 [EMAIL PROTECTED] 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:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#856
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?
Martin
union {
#ifndef _RWSTD_NO_LONG_DOUBLE
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
