Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 11:25:32 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FC07@exchmail01.Blue.Roguewave.Com>
Thread-Topic: svn commit: r669735 - in /stdcxx/branches/4.3.x:
 include/rw/_meta_other.h include/type_traits
 tests/utilities/20.meta.trans.other.cpp
Thread-Index: Acja0scuRr/LTuKjQ1WGhT33OkZUJAAAB6wQ
References: <20080619225234.8583F23889F7@eris.apache.org>
 <4861555E.7050104@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBF2@exchmail01.Blue.Roguewave.Com>
 <486416A5.1060607@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FC04@exchmail01.Blue.Roguewave.Com>
 <48691082.9090905@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

Martin Sebor wrote:
>
>Travis Vitek wrote:
>> =20
>>=20
>> 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?
>>>
>>=20
>> 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 c++std-lib@accu.org yet,

Yes, I am finally subscribed.=20

>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...
>
>>=20
>> This problem comes up in the definition of=20
>__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
>
>>=20
>>     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;
>>=20
>> Travis
>
>