Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2008 3:05 PM
To: [email protected]
Subject: Re: type_traits progress
Travis Vitek wrote:
Eric Lemings wrote:
Travis Vitek wrote:
...
As an example, the array traits above are all closely related
and their
implementations are similar. There are five traits, and
those traits
span three sections of the standard.
I'm open to doing some type of grouping, we just need to
understand how
we want to group them and then how we want to name the files.
The term you're looking for is cohesion. :) I kinda like this
organization. Couple things though.
Why put __rw_decay, a single helper trait in its own header?
Well decay deals with conversion from array to pointer and
function to
function pointer conversions. I can't necessarily put it into both
_meta_array.h and _meta_func.h, so I figured it would be
best to put it
into a file by itself.
FWIW, I see no problem with bundling groups of traits together
even if some of them are unlikely to be used in the rest of the
lib, just as long as their implementation isn't too big (i.e.,
doesn't bloat translation units and unnecessarily increase
compilation time).
Well when it comes to metaprogramming, there's almost always a
tradeoff in these two respects. Either the translation unit
size increases or compile times increase.
They tend to go hand in hand. But you probably meant the size
of the generated object code.
But you're right:
we should minimize both whenever possible.
BTW, which of these two should be the preferred: comile-time
computations (metaprogramming) or runtime processing? I would
say compile-time even though that will signficantly impact us
developers but I think users would prefer this since they do
not build nearly as often.
I'm sure you're right in the majority of cases. But as John Lakos
writes in his Large-Scale C++ Software Design compilation time is
exceedingly important for large code bases with millions of lines
of code: http://www.amazon.com/dp/0201633620
The problem with metaprogramming is that many compilers weren't
designed for the kind of involved computation that some of these
algorithms require, so their performance really blows. It's a
fun exercise to time the compilation of a non-trivial metaprogram
(e.g., sorting a typelist) while watching its memory consumption.
Martin