From dev-return-8058-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Mon Jun 30 19:17:19 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 99269 invoked from network); 30 Jun 2008 19:17:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jun 2008 19:17:19 -0000 Received: (qmail 33663 invoked by uid 500); 30 Jun 2008 19:17:20 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 33642 invoked by uid 500); 30 Jun 2008 19:17:20 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 33631 invoked by uid 99); 30 Jun 2008 19:17:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jun 2008 12:17:20 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jun 2008 19:16:29 +0000 Received: from nebula.bco.roguewave.com ([10.70.3.27]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m5UJEmcZ031796 for ; Mon, 30 Jun 2008 19:14:48 GMT Message-ID: <486930A8.9080208@roguewave.com> Date: Mon, 30 Jun 2008 13:14:48 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: dev@stdcxx.apache.org 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 References: <20080619225234.8583F23889F7@eris.apache.org> <4861555E.7050104@roguewave.com> <486416A5.1060607@roguewave.com> <48691082.9090905@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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