From dev-return-8210-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Thu Jul 17 17:46:14 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 30712 invoked from network); 17 Jul 2008 17:46:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Jul 2008 17:46:14 -0000 Received: (qmail 73076 invoked by uid 500); 17 Jul 2008 17:46:13 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 73007 invoked by uid 500); 17 Jul 2008 17:46:13 -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 72996 invoked by uid 99); 17 Jul 2008 17:46:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jul 2008 10:46:13 -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; Thu, 17 Jul 2008 17:45:20 +0000 Received: from nebula.bco.roguewave.com ([10.70.3.27]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m6HHjieS018892 for ; Thu, 17 Jul 2008 17:45:44 GMT Message-ID: <487F8548.5030205@roguewave.com> Date: Thu, 17 Jul 2008 11:45:44 -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: fallback support for traits References: 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: > I've already implemented fallback support for many traits. Here is a > list of those that I can think of off of the top of my head... > > __rw_is_class > __rw_is_union > __rw_is_empty > __rw_is_polymorphic > __rw_is_abstract > __rw_is_convertible > __rw_is_base_of > __rw_has_trivial_ctor > __rw_has_trivial_copy > __rw_has_trivial_assign > __rw_has_trivial_dtor > __rw_has_nothrow_ctor > __rw_has_nothrow_copy > __rw_has_nothrow_assign > > All of the fallbacks are supposed to provide a correct result where > possible, otherwise they should return a pessimistic result. I.e. The > fallback __rw_has_trivial_ctor::value will be true for all (possibly > cv-qualified) scalar types, but will evaluate to false for class types > (struct, union or class). > > Now I have to figure out what to do for a few more traits. Specifically > __rw_alignment_of<> and __rw_aligned_storage<>. As it stands now, these > traits require definition of _RWSTD_TT_ALIGN_OF() and > _RWSTD_TT_ALIGNED_POD() to be defined. If the macros are not provided, > we will see a compile failure. But only for the unusual specializations where the alignment isn't the same as one of the fundamental types, right? > > As I see it, my options are... > > 1. put code that will prevent instantiation in the the type > declaration (i.e. static_assert) > 2. provide a suitable default that is not correct, but can be > used to detect the failure > 3. disable traits entirely by defining _RWSTD_NO_EXT_CXX_0X if > the macros have not been defined > 4. disable the affected traits (and their tests) if the macros > have not been defined > > As I see it, option 4 is probably best. Especially given the recent > discussion of removing all three alignment traits in favor of the new > alignof and alignas keywords and non-trivial unions. We still need to write up the issue... As for providing the traits only conditionally, I'm not sure that's the best approach. If we feel it likely that some of them will end up getting yanked from the working paper we should probably avoid providing them at all, otherwise we might be stuck maintaining them for a long time. Providing them only for some platforms would also make them difficult to use portably (we'd have to expose some kind of config macro for users to check whether the trait is defined or not). So my preference would be either (2) or (5), with option 5 being to disable the aligned traits unconditionally until we know for certain that they aren't going away. Out of curiosity, what do other implementations do? Martin > > Input anyone? > > Travis