From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-10-11 08:39:09
David B. Held wrote:
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> First of all, my vote is to accept enable_if.
>>While this is necessary for the MPL itself, it puts a price on
> Or maybe it adds value to other components, since working
> with MPL gives you more out-of-the-box stuff to do with them.
Of course, I don't doubt the benefits of MPL. When you need it, it's a
wonderful tool to have.
>>It depends on conventions others have to fulfill. The
>>implementation and documentation of enable_if is much
>>larger than what it would probably be without the MPL.
> But is that really a bad thing? std::sort() is much more
> complicated than it would be without the STL. Abstraction
> has its price, but we pay it because of the reward.
Maybe I'm nitpicking now, but from MPLs POV, the naming convention is to
use _c for the "special" case that you want to provide the value
directly. But I wonder if this was a good choice as it seems to me that
from an outside perspective, it would make more sense to add a _t the
MPL-version of the general part. This would IMHO be more consistent and
remove the small price for people that use enable_if without caring
about the MPL. But that is actually the smallest issue, I think the
separation of components (with separate documentation!) is much more
important. Having template-traits is nice, but when they are hidden
inside MPL and not documented, they are close to useless for me. Look at
the history of enable_if: It was developed several times independently
IIUC and just now we are giving it the attention it deserves as a
valuable technique on it's own. I'm in no way against the MPL, I just
would like to make people think about factoring out components. My
experience is, that it's these little helpers that are often more needed
than large libraries and frameworks in my job. It's also easier to
convince your boss that you need a small tool like enable_if instead of
the whole MPL, YMMV.
> Well, there is a danger in letting MPL become the Borg.
> On the one hand, we should seek to refactor stuff that doesn't
> need to be in MPL into independent libraries that can be
> used on their own. Which means that if traits could all be
> moved to the type traits library, I don't see why they shouldn't.
Exactly. As Dave also mentioned: type-traits and tuples are also good
examples for things that would well be seen as MPL components, but that
are currently (and luckily) independent from the outside perspective.
Whether or not they use some parts of the MPL (which uses the
Preprocessor Library, which uses...) is another story.
> The problem is that MPL is kinda like an RTL for the compile-
> time world. It provides a lot of fundamental services that
> other meta-stuff can use, which is also part of its purpose.
> So maybe people who want to do a lot of meta-stuff will just
> have to get used to it in the way we are used to linking to an
> RTL every time we build a program.
As I said, I don't mind the dependency. I just think that we should have
separate and independent documentation of some parts...
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk