Return-Path: 
 <dev-return-7959-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 40074 invoked from network); 24 Jun 2008 23:11:44 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 24 Jun 2008 23:11:44 -0000
Received: (qmail 25792 invoked by uid 500); 24 Jun 2008 23:11:46 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 25774 invoked by uid 500); 24 Jun 2008 23:11:45 -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 25763 invoked by uid 99); 24 Jun 2008 23:11:45 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jun 2008 16:11:45 -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
 209.85.132.250 as permitted sender)
Received: from [209.85.132.250] (HELO an-out-0708.google.com) (209.85.132.250)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jun 2008 23:10:55 +0000
Received: by an-out-0708.google.com with SMTP id d33so719537and.97
        for <dev@stdcxx.apache.org>; Tue, 24 Jun 2008 16:11:13 -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=R2aVAqM8CWmzqVvGiC5C1x8JsiYtBOos5PCRTTJVx6g=;
        b=Lu+YYW/l2+kwKtBcXnlL2EndB1ygFJAGxcJt8XA873yLn27GpKoLaXpEb4xOfMj8XL
         txVEI/sMMiaBIXV/CpIvWza7cFN6wCDKkpJLLkqtO2VvV7NDS7OtI5PKABnihPbNr61s
         3J+BUQOv526S3coBOlt1mnH91uM4zSaQs38AA=
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=Z+oz75MH+eOejRQs1rg2IBHzHf0dM+DT6J9R58Uds1dfaCiMGWY3q0vMvf2ojM91jL
         FpFJBb/HDVqHna29KKOWoxmsYVjFle0wDJb2BM2XRMJeyqE9wxieXrgcLQE6BbMzFFiA
         8rYjdMBAA+pOYEkknh9RPzSXp4gSFruUjfbB8=
Received: by 10.100.33.11 with SMTP id g11mr16842237ang.128.1214349073592;
        Tue, 24 Jun 2008 16:11:13 -0700 (PDT)
Received: from localhost.localdomain ( [71.229.200.170])
        by mx.google.com with ESMTPS id u6sm16485510pyb.0.2008.06.24.16.11.12
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 24 Jun 2008 16:11:13 -0700 (PDT)
Message-ID: <48617F0F.2020100@roguewave.com>
Date: Tue, 24 Jun 2008 17:11:11 -0600
From: Martin Sebor <sebor@roguewave.com>
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: Some internal aliases for __rw_integral_constant?
References: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EA@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EA@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

Eric Lemings wrote:
>  
> Propose adding the following defs (or something similar) to
> <rw/_meta_help.h> primarily for our own convenience:
>  
> template <bool _Bool>
> class __rw_bool_const: public __rw_integral_constant<bool, _Bool> {};

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.)

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 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:

#define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant<bool, B>

Usage:

      _RW::__rw_bool_const<bool, false>
   vs
     _RWSTD_BOOL_CONST (false)

>  
> template <int _Int>
> class __rw_int_const: public __rw_integral_constant<int, _Int> {};
>  
> template <_RWSTD_SIZE_T _Size>
> class __rw_size_const: public __rw_integral_constant<_RWSTD_SIZE_T,
> _Size> {};
> 
> The name __rw_integral_constant is a bit too long for the amount of
> usage that I'm anticipating.

AFAICS, there are just 9 occurrences of the size_t specializations
but none of the int one.

Martin

> Or am I being premature?
> 
> Thoughts?  Alternatives?
> 
> Brad.