Return-Path: 
 <dev-return-7972-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 70587 invoked from network); 25 Jun 2008 18:03:24 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 25 Jun 2008 18:03:24 -0000
Received: (qmail 9785 invoked by uid 500); 25 Jun 2008 18:03:26 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 9774 invoked by uid 500); 25 Jun 2008 18:03:26 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 9763 invoked by uid 99); 25 Jun 2008 18:03:26 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jun 2008 11:03:26 -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; Wed, 25 Jun 2008 18:02:36 +0000
Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com
 [10.22.129.22])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m5PI0tjI014226
	for <dev@stdcxx.apache.org>; Wed, 25 Jun 2008 18:00:55 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: __rw_and (Was RE: Some internal aliases for
 __rw_integral_constant?)
Date: Wed, 25 Jun 2008 12:00:20 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05ED@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: __rw_and (Was RE: Some internal aliases for
 __rw_integral_constant?)
Thread-Index: AcjWT8aQUbAwy0L0SHaqadR/pakMOgABsCywACS3SBAAAJtDQA==
References: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EA@exchmail01.Blue.Roguewave.Com>
 <48617F0F.2020100@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EB@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EC@exchmail01.Blue.Roguewave.Com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]=20
> Sent: Wednesday, June 25, 2008 11:41 AM
> To: dev@stdcxx.apache.org
> Subject: __rw_and (Was RE: Some internal aliases for=20
> __rw_integral_constant?)
>=20
> =20
>=20
> > -----Original Message-----
> > From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]=20
> > Sent: Tuesday, June 24, 2008 6:01 PM
> > To: dev@stdcxx.apache.org
> > Subject: RE: Some internal aliases for __rw_integral_constant?
> >=20
> > =20
> >=20
> > > -----Original Message-----
> > > From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of=20
> > Martin Sebor
> > > Sent: Tuesday, June 24, 2008 5:11 PM
> > > To: dev@stdcxx.apache.org
> > > Subject: Re: Some internal aliases for __rw_integral_constant?
> > >=20
> > > Eric Lemings wrote:
> > > > =20
> > > > Propose adding the following defs (or something similar) to
> > > > <rw/_meta_help.h> primarily for our own convenience:
> > > > =20
> > > > template <bool _Bool>
> > > > class __rw_bool_const: public __rw_integral_constant<bool,=20
> > > _Bool> {};
> > >=20
> > > I was going to suggest the same thing this morning when I noticed
> > > how pervasive __rw_integral_constant<bool, _Bool> seems to be in
> > > traits definitions (I count 41 occurrences) and thinking that it
> > > would make them less verbose. (With a different spelling of _Bool
> > > to avoid potential clashes with the C99 name.)
> >=20
> > Good point.
> >=20
> > >=20
> > > I didn't because the only beneficiaries of the change would be us
> > > (a fairly small notational convenience) and I wasn't sure the cost
> > > in terms of the added complexity and compilation time was=20
> worth it.
> > > I contemplated suggesting a macro for the same purpose instead but
> > > decided against it on the assumption that it probably wouldn't be
> > > very popular ;-) But now that the cat's out of the bag and you're
> > > asking about alternatives let me throw it out there:
> > >=20
> > > #define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant<bool, B>
> > >=20
> > > Usage:
> > >=20
> > >       _RW::__rw_bool_const<bool, false>
> > >    vs
> > >      _RWSTD_BOOL_CONST (false)
> > >=20
> >=20
> > Looks good to me.  I'll just add _RWSTD_BOOL_CONST for now.
>=20
> Okay, another proposal for inclusion though this particular utility
> may be a stretch unless you understand variadic templates very well.
>=20
> 	template <bool...>
> 	struct __rw_and;
>=20
> 	template <>
> 	struct __rw_and<>: std::true_type {};
>=20
> 	template <bool _Bool0, bool... _BoolN>
> 	struct __rw_and<_Bool0, _BoolN...>
> 	    : _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
> {};

Actually that should probably be something like:

	: std::conditional<_Bool0, __rw_and<_BoolN...>,
                         std::false_type>

Assuming the compiler isn't smart enough to short-circuit such
instantiations already.

Brad.