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
 209.85.132.246 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=QhrAh8I0m90OwfrykN2oiF32MYxOVeFDrrBt17sDyoCahBSNpuwQAXBVXWSBQX6jyF
         bNg+aNdwOUzZ1sJUHF4ObYudjmaUzJwN9t72z4e1yYlr1TlbelJcuog0xa5f1YxojvHM
         JNPV6umqIDGhpuK//Epi2VrQOaOJ8rkpKNtzk=
Message-ID: <4863D25E.5070005@roguewave.com>
Date: Thu, 26 Jun 2008 11:31:10 -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>
 <4863B97C.7050304@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05F0@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05F0@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:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Thursday, June 26, 2008 9:45 AM
>> To: dev@stdcxx.apache.org
>> Subject: Re: __rw_and (Was RE: Some internal aliases for 
>> __rw_integral_constant?)
>>
>> 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?
> 
> I could try but you would want to read it about as much as I would want
> to write it.  :)
> 
> Basically, it would require all the hackery required for simulating
> variadic templates.  Not pretty.

Maybe I misunderstood the purpose of the __rw_and template. I wasn't
asking to see a solution w/o variadic templates, but one without
__rw_and. If I understand your response correctly, you're proposing
to add __rw_and to hide the dual implementation of ANDing variable
numbers of constraints, one with variadic templates and the other
without. I.e., __rw_and would be more than just syntactic sugar.
Correct?

> 
>> 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.
> 
> Right.  The way I see it, utilities like this are indended to simplify
> the required metaprogramming code.  In order to do that though, other
> developers would have to reuse it.  :)
> 
> That's why I said at the bottom of the email that I'll probably hold off
> on moving it up the chain of includes to a more generic header where it
> would be more reusable until such a time when other developers find more
> need for it.  (I doubt tuples will be the only place requiring
> compile-time logical operators.)  But it's posted now so we're all aware
> of it at least.

I'm not sure what you mean by "moving it up the chain." Sounds to
me like you need __rw_and to implement tuple and are asking if the
template should be moved into some common header and made use of
in other areas of the implementation. If that's the case, I agree
that we definitely should reuse as many helpers as we can and
avoid reinventing the wheel.

> 
> BTW, is template recursion really costly in terms of compile times?

I've never benchmarked it but it's a commonly held opinion that
it is exceedingly costly, primarily because C++ compilers weren't
designed with template metaprogramming in mind.

You can take as anecdotal evidence the simple little example below
which takes about 7 times longer to compile with gcc 4.3 when
TEMPLATE is defined than when it isn't. The -fstats option also
shows that the template cases uses up 2.5 time more memory.

#ifdef TEMPLATE
template <int N> struct sum { enum { v = N + sum<N - 1>::v }; };
template <> struct sum<0> { enum { v }; };
int N = sum<500>::v;
#else
int N = 500 + 499 + 498 + 497 + /* ... */ + 3 + 2 + 1 + 0;
#endif

Martin