Martin Sebor wrote: > >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?
No, I'm just poking another hole in the policy of always putting the most strictly aligned member first. If I can't reliably determine the most strictly aligned member, it makes it a tad difficult to declare it first. So now the policy becomes 'put the one that you think has the most stringent alignment requirement on platform X'. >Btw., if you're not subscribed to [EMAIL PROTECTED] yet, Yes, I am finally subscribed. >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://tinyurl.com/5da3l8 I tinyurl'd this to fit into a 70 character line. According to the issue, aligned_union<> is supposedly being supersceeded by 'extended unions', but I understand that some things could be done with alignas(). If alignas() is supported, then aligned_storage<> can, for the most part, be implemented trivially, but aligned_union<> still requires some work. I realize that this is really not the place to argue against its removal, but I don't really understand why either should be removed. At the very least, both of these allow library implementations to support functionality when the compiler support doesn't exist yet (I can implement aligned_union<>, but I most definitely cannot implement alignas()). Not only that, but I honestly find code using the trait much more readable than using the keyword directly. >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? I don't. As I mentioned above, I'm poking holes in the policy. > >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 > >
