[boost] Re: MPL containers and algorithms

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-08-12 20:35:07

"Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
news:153001c24071$34b897b0$60fb5dd5_at_pc...
>Take one of the simplest algorithms, factorial.<

This example has two problems: (1) it's not a "real-world" example because I
don't find myself running around and computing factorials of all possible
types at compile time; (2) It doesn't justify MPL's design that imitates
STL's design; (3) it really works more against your viewpoint :o). Ok,
that's three problems.

>Using MPL, you might write it like as follows. Explanation for the apparent
increase in complexity, follows below here. It is to get the same generic
quality as the run-time version.<

template<class V>
struct factorial
{
  typedef typename V::type Value;

  typedef typename apply_if<equal_to<Value,value<Value,0> >,
    value<Value,1>,
    mul<Value,factorial<prev<Value> > >
  >::type type;
}

That's it, 9 lines of code (7 without braces), one template, two typedefs,
done. :)<

...relying on a ton of scaffolding, some of which doesn't even exist! No
more questions, your honor. I rest my case.

Besides, I frankly find the code abominable. It attempts to look and feel
like runtime C++, and to me it doesn't do it.

>It could have been written simpler, using "*", "-", etc., if you assumed
the
value passed in was int, or int_c, or something like that. However, with the
above form, it may be used to compute the factorial of any value type, such
as integral_c, fixed_c and rational_c.<

But who wants to compute factorials at compile time for so many types? Where
is the "real world" feel in this example?

>For example, if you create a new value type, like double_prec, you can use
it in the above function, unchanged. :)<

The smilye says it all...

[I will snip the long explanation you provide for the *simplest* example,
factorial, implemented in MPL. Using some of MPL. Using some not yet defined
parts of MPL. Using some novel ideas of your own. Using a hard to follow
syntax. I repeat, if that's the *simplest* example, we're really in bad
shape here.]

>Enough of that version.<

Agreed :o).

>Let's look at the typical way it might be done using
template specialisations. Feel free to make another version, here, Andrei.
After all, this is your part of the argument. :)<

Your code is fine.

>Let's make one that works on int, only, first. Then we'll try to expand it.
("try" being the operating word, here. :) ).<

Do we ever try to expand it? I repeat, this is not a good example. Let's try
to come up with an example of code that people might actually need.

Anyway, the example does not justify the existence of various containers in
MPL; it only says that some of MPL's utilities are useful.

>When it comes to the request of showing how MPL may solve a real-life
problem, I think it's pertinent to mention that larger programs typically
consist of smaller parts. Therefore, unless you get the smaller parts to
work, the larger program won't work, either.<

My point exactly :o).

>> That doesn't, in and of itself, really say anything. Of course what's
most
> familar is also easiest. I think that a newcomer, however, can be
> comfortable very soon with using dot-typelists than with an extremely
> complicated incomplete compile-time emulation of the STL.<

>I think it would be better to ask newcomers that. :) I don't think that is
given. As mentioned, it may well be the other way around.

Similar arguments have been used to argue for teaching C++ the C-first way,
as the standard library and STL was considered "advanced". When the truth is
that if you teach C++ as a high-level language, starting very early with the
standard library and STL, people tend to find it easier to learn good
programming that way, than having to suffer through low-level C, first.

I think it may be similar with MPL. It provides an additional abstraction,
so you don't have to write the explicit specialisations, etc., but can write
code in something that may be more familar, resembling run-time code.<

The comparison doesn't hold. It's exactly the other way: why would people
have to suffer when things can be done easier.

Again, let's steer away from comparisons and see facts for what they are.

>> My opinion is that C++ will never be there, simply because its template
> engine is very different, and much more scarce, than its runtime
> counterpart. That's why MPL seems to me like an interpreter written in awk
> or advanced threading in Visual Basic: wow, look, it can be done, how
> quaint - but man, you just get that feeling that the tool is totally
> inappropriate for the job. That's why I also wouldn't be keen of
> manipulating collections of 10,000 types at compile time in C++.<

>Well, as I understamd, MPL is being used in real-life. Dave Abrahams has
mentioned using it, for example.<

I didn't ever say MPL isn't used or can't be used.

>Perhaps my simple example above can shed some light on this.<

No light to my sore eyes :o). Fortunately, no heat either :o).

Andrei