From dev-return-7735-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Mon Jun 02 22:26:19 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 57444 invoked from network); 2 Jun 2008 22:26:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jun 2008 22:26:19 -0000 Received: (qmail 79699 invoked by uid 500); 2 Jun 2008 22:26:21 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 79635 invoked by uid 500); 2 Jun 2008 22:26:21 -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 79624 invoked by uid 99); 2 Jun 2008 22:26:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 15:26:21 -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 64.233.178.248 as permitted sender) Received: from [64.233.178.248] (HELO hs-out-0708.google.com) (64.233.178.248) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 22:25:28 +0000 Received: by hs-out-0708.google.com with SMTP id 54so820789hsz.15 for ; Mon, 02 Jun 2008 15:25:45 -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=gNbgyd3X+vZMhMyBFoUbm623mssa23pIJZFfAfFT9BE=; b=bqb8G9pfDHgnCmWECSmSKr+zdJw2HPw2Y030kua0DHGXNZLuebL/fnd42RR2aDvtEqDNF6t83iBSvF9zdiZ6jflsHhisqqZxEvx4xjb6ItHqKhmxS6HLnrMJt5oHwYJzJT/O6gy//hHMZNmspfmy4AdhJrRHBWr+hJj14kdiUCE= 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=xf+iWpEG4r1glW11cG5WwAIl8fhDI1TIBovKg5Ix/DSsUI1PAIA5XRJQKrjjwogwTi6Uta3j8g0F8wnLCjkYqrNOhVkmXLyu080t+wPw6Q9IP+pcqhd3Crh4Tc37I6KW09m/oZ73/hnIk1e78XT2957Ifi8XTgXHnvSvnaqOjfg= Received: by 10.90.66.14 with SMTP id o14mr1015405aga.18.1212445545080; Mon, 02 Jun 2008 15:25:45 -0700 (PDT) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id a78sm6262431pye.19.2008.06.02.15.25.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Jun 2008 15:25:43 -0700 (PDT) Message-ID: <48447364.9080209@roguewave.com> Date: Mon, 02 Jun 2008 16:25:40 -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: type_traits progress References: <483B79A1.4070808@roguewave.com> <483C67BA.6070209@roguewave.com> <48401E00.2090709@roguewave.com> <48409378.3010407@roguewave.com> <48445493.4080400@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:sebor@roguewave.com] >> Sent: Monday, June 02, 2008 2:14 PM >> To: dev@stdcxx.apache.org >> Subject: Re: type_traits progress >> >> Eric Lemings wrote: >>> >>> >>>> -----Original Message----- >>>> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] >>>> Sent: Friday, May 30, 2008 6:28 PM >>>> To: dev@stdcxx.apache.org >>>> Subject: RE: type_traits progress >>>> >>>> >>>> >>>> Martin Sebor wrote: >>>>> Travis Vitek wrote: >>>>> [...] >>>>>>> Right. That could be another wrinkle. Our traits won't >>>>>>> work with generic code that takes integral_constant >>>>>>> by reference. >>>>>> I don't really see the motivation, but it is obvious that >>>>>> the committee thought it was important for the standard >>>>>> traits to do so, so we should probably follow suit in our >>>>>> internal implementation. >>>> Can you think of a reason why this 'feature' would be important? >>>> >>>>>> If we did decide to do this then we would probably want >>>> our own write >>>>>> __rw_integral_constant and use that internally to avoid namespace >>>>>> pollution? Then I'd assume we'd want something like the following >>>>>> example for is_const... >>>>> Yes, I think this is close to what we want. The only >> thing that bugs >>>>> me about it is... >>>>> >>>>>> template >>>>>> struct __rw_integral_constant >>>>>> { >>>>>> static const T value = v; >>>>>> typedef T value_type; >>>>>> typedef integral_constant type; >>>>> ...this backward dependency on integral_constant, but I >> don't see how >>>>> to break it without template typedefs. I don't think there's >>>> a compiler >>>>> out there that supports them yet. >>>> Actually, this was originally a typo on my part, but I do see >>>> where this >>>> is going. I haven't read about template typedefs, but it seems that >>>> there would be a serious problem caused by the cyclic dependency. >>> Yeah it looks like a typo to me too. Should it be: >>> >>> typedef __rw_integral_constant type; >>> >>> In all cases I've seen, `type' refers to type of self for identity >>> properties. This typedef would not hold up the identity property. >> IIUC, for every specialization X of integral_constant, this >> must hold: >> >> is_same::value == true >> >> With integral_constant derived from __rw_integral_constant >> the condition would fail. > > Not if it defined its own `type'. > > template > struct integral_constant: __rw_integral_constant > { > typedef integral_constant type; > }; Good point! This would effectively break the problematic dependency, wouldn't it, Travis? Martin