From dev-return-8024-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Jun 27 05:13:45 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 87373 invoked from network); 27 Jun 2008 05:13:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jun 2008 05:13:45 -0000 Received: (qmail 53119 invoked by uid 500); 27 Jun 2008 05:13:47 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 53097 invoked by uid 500); 27 Jun 2008 05:13:47 -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 53086 invoked by uid 99); 27 Jun 2008 05:13:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2008 22:13:47 -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: domain of msebor@gmail.com designates 74.125.46.28 as permitted sender) Received: from [74.125.46.28] (HELO yw-out-2324.google.com) (74.125.46.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 05:12:56 +0000 Received: by yw-out-2324.google.com with SMTP id 5so154561ywb.53 for ; Thu, 26 Jun 2008 22:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:sender; bh=0ye6a7iJTxWcc+ZEYMdsXJIIwOgSJCl8u+Qe38rhbac=; b=uua8NgntwW0dS24M+jrDLY+LKwqW58YcIVQshpDOOf4i8fJFL84ShOgbd3uxXkx44G IZVe03/I0pAILmpqFWTN/RqbnsrenrEff/fp8vZk2+sJG5w77DHzkmePAra75QRHVryc KFwjIHCnQyJPeipwEhoVjcjtJeNAMu0PiVuH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding:sender; b=uqr7gaHNTDFQPJPKVVJFNI98NGOmQP28Qu2GepqzbxacOMX/Pa6e6AkBOVAd13NWhg WjYJyFXDuswhKJNTtQXBcY3lw3eqP/yb+DtT74/Ksa7KvRxo/edp68lJMtX6mjkZxpgj dWO+gGW/nKkEilLq/OotpLMp9Z6UOGgWEdwcM= Received: by 10.150.92.6 with SMTP id p6mr1465459ybb.243.1214543576363; Thu, 26 Jun 2008 22:12:56 -0700 (PDT) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id n45sm911200pyh.29.2008.06.26.22.12.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Jun 2008 22:12:55 -0700 (PDT) Message-ID: <486476D5.5070805@roguewave.com> Date: Thu, 26 Jun 2008 23:12:53 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: implementation of Unary Traits References: <48642A07.4010201@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org Eric Lemings wrote: > > >> -----Original Message----- >> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor >> Sent: Thursday, June 26, 2008 5:45 PM >> To: dev@stdcxx.apache.org >> Subject: implementation of Unary Traits >> >> The implementation of Unary Traits (e.g., is_void) uses explicit >> specialization on all four combinations of cv-qualifiers for each >> trait (plain, const, volatile, and const volatile). I'm wondering >> if the alternative approach of stripping the qualifiers before >> "dispatching" to just one explicit specialization has been >> considered. The potential advantage of this approach is fewer >> declarations, smaller translation units, and thus (presumably) >> faster compilation. > > Though I'm using a relational (binary) type trait, I'm getting warnings > because the cv-qualifiers are not being stripped. A test case is always helpful: #include int main () { return !std::is_convertible::value; } Seems like is_convertible might need to strip top-level cv qualifiers from the types. What do you think, Travis? Martin > > gcc -c -I/work/stdcxx/branches/4.3.x/include/ansi -D_RWSTDDEBUG > -pthread -I/work/stdcxx/branches/4.3.x/include > -I/build/stdcxx-4.3.x-15D/include > -I/work/stdcxx/branches/4.3.x/tests/include -std=gnu++0x > -D_RWSTD_EXT_CXX_0X -W -Wall -Wcast-qual -Winline -Wshadow > -Wwrite-strings -Wno-long-long -Wcast-align > /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h: In > instantiation of '__rw::__rw_is_convertible_impl': > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:93: > instantiated from '__rw::__rw_is_convertible_3 false>' > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:122: > instantiated from '__rw::__rw_is_convertible_2' > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:145: > instantiated from '__rw::__rw_is_convertible_1 false>' > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:163: > instantiated from '__rw::__rw_is_convertible' > /work/stdcxx/branches/4.3.x/include/tuple:68: instantiated > from 'std::tuple::_C_is_compatible' > /work/stdcxx/branches/4.3.x/include/tuple:123: instantiated > from 'std::tuple<_Types>::tuple(_TypesU&& ...) [with _TypesU = int, > _TypesT = const int]' > > /work/stdcxx/branches/4.3.x/tests/utilities/20.tuple.cnstr.cpp:103: > instantiated from here > /work/stdcxx/branches/4.3.x/include/rw/_meta_rel.h:77: warning: > type qualifiers ignored on function return type > > Brad.