Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-12 22:27:59

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

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

I run around (in circles) just computing factorials in my head. :)

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

This is not the part that bothers me.  You can use some of MPL's facilities in
the above example (factorial) and implement the concept in a simpler fashion.
For instance, you could get rid of the type abstraction if you wanted to, etc..
This is just putting pieces of the MPL together and nothing is forcing anyone to
do that.

Granted, I don't think that calculating factorials at compile time is much more
than a neat trick, but the example could be extended to handle some type of
numeric computation that actually is useful.

The most relevant problem with the example is that it has nothing to do with
sequences or containers--which is the primary thing that Andrei and I are
debating.  Of course, there are two other problems.  This little factorial
allows you to calculate a factorial of two compile-time constants: (pseudo-code
follows)

factorial( constant, constant )

What about these:

factorial( constant, runtime-value )
factorial( runtime-value, constant )

The same goes for 'pow', which is more reasonable in general programming than
factorial.

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

In a sense, it does look like runtime use of the STL, but the problems are all
different.  Most of it is about template indirection rather than functionality.

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

Andrei, are you trying to say that computing a compile-time factorial of a
floating-point number at compile-time is not worthwhile? :)

It would be possible to implement arbitrary precision arithmetic at compile-time
this way.  --But these are all academic until such things are actually
*necessary* to produce real runtime functionality with metaprogramming.  I could
implement high-precision arithmetic this way, yes, but what's the point unless I
actually *need* it.

> >Enough of that version.<
>
> Agreed :o).

This is the most amusing email that I've read in days. :) We have a massive
difference in perspective here IMO, academic vs. practical.

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

More importantly, this example has nothing to do with sequences.

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

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

I agree.  The MPL should be able to stand on its own without the STL backing it
up.

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

I'd like to point out also that Loki's typelists are used in real life also.
Further, idioms implemented with typelists are used in real life, and Loki
doesn't have sequence abstraction.  The argument doesn't fly because bad code is
being used all over the place ( not to say that the MPL is bad code for what it
is supposed to be doing! ).  The question is, could all of the uses of the MPL
in Boost (in the Python lib, etc.) be recreated *without* sequence abstraction?
The other Boost libraries are primary examples of real-life code; if they don't
need it, why are we (as in not me) _assuming_ that it's necessary?  (We've had
tons of examples of different sequence types, but never any reasons why they
can't use some standard type).  <-- and 10,000 elements is not an answer--I have
this weird gut feeling that if I even tried to run a 10,000 element sequence (in
*any* form) through an MPL algorithm, every compiler that I have will choke and
die miserably--either that, or not finish until *I* choke and die.

Paul Mensonides