incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
Date Thu, 26 Jun 2008 17:31:10 GMT
Eric Lemings wrote:
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Thursday, June 26, 2008 9:45 AM
>> To:
>> 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.

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

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


View raw message