Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 64.233.184.226 as permitted sender)
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=a4hwr9kksGpt7jdgRqyAhl9JMXYoJfkqy/YOjkAK5T+Y+fLZtilUbo6+gGqX6aBU0f
         rVeDnC9ZCBYVsaOeogX+uKxFrRTsM0Ptyg3AxeEQ3CtBlf7Qq7pb1xpkwE5TpcwljokY
         WilImeRQztAVu9rJdg108cSYbsygWjEk7Q3BA=
Message-ID: <4863B97C.7050304@roguewave.com>
Date: Thu, 26 Jun 2008 09:45:00 -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: __rw_and (Was RE: Some internal aliases for
 __rw_integral_constant?)
References: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EA@exchmail01.Blue.Roguewave.Com>
 <48617F0F.2020100@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EB@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EC@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05EC@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Eric Lemings wrote:
>  
[...]
> Okay, another proposal for inclusion though this particular utility
> may be a stretch unless you understand variadic templates very well.

Can you show what the code looks like w/o __rw_and for comparison?

In general, an important design principle behind stdcxx is efficiency,
both in time and in space. And in terms of time, both compilation as
well runtime efficiency is important. In contrast to the ordinary
kind, template metaprogramming tends to increase compilation times
much more noticeably. In C++ 0x a good amount metaprogramming code
is dictated by the standard already but as a rule we need exercise
restraint when introducing templatized helper code, especially
when template recursion is involved.

Martin

PS As an aside, concepts should obviate the need for __rw_and and
similar metaprogramming tricks.


> 
> 	template <bool...>
> 	struct __rw_and;
> 
> 	template <>
> 	struct __rw_and<>: std::true_type {};
> 
> 	template <bool _Bool0, bool... _BoolN>
> 	struct __rw_and<_Bool0, _BoolN...>
> 	    : _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
> {};
> 
> For example:
> 
> 	template <class... _TypesT>
> 	struct tuple {
> 
> 	    template <class... _TypesU>
> 	    struct __rw_is_compat
> 	        : __rw_and<std::is_convertible<_TypesT,
> _TypesU>::value...> {
> 
> 	        static_assert (sizeof... (_TypesT) == sizeof...
> (_TypesU),
> 	                       "tuple sizes must be equal");
> 	    };
> 
> 	};
> 
> Here are some quick tests that I tried out on it:
> 
>     typedef tuple<char, int, long> T1;
>     std::cout << T1::__rw_is_compat<char, short, int>::value
>               << std::endl;
> 
>     std::cout << T1::__rw_is_compat<const char, const int, const
> long>::value
>               << std::endl;
> 
>     std::cout << T1::__rw_is_compat<float, int, long>::value
>               << std::endl;
> 
>     std::cout << T1::__rw_is_compat<void*, int, long>::value
>               << std::endl;
> 
>     // fires the static assertion
>     //std::cout << T1::__rw_is_compat<char, short>::value
>               //<< std::endl;
> 
> Might just save that one for later but worth posting at least.  :)
> 
> Brad.