incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
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 19:14:48 GMT
Travis Vitek wrote:
>  
> 
> 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'.

That's essentially been the guideline in existing code.
What do you suggest as an improvement?

Martin


Mime
View raw message