Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Thursday, June 26, 2008 9:45 AM
To: [email protected]
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

Reply via email to