Re: [boost] [MPL] Potential use for multiple sequence types

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-09 18:06:25

>From: "Paul Mensonides" <pmenso57_at_[hidden]>

>>From: "Terje Slettebø" <tslettebo_at_[hidden]>

>> > Either way, 10,000 element containers is going *way* beyond real world
>> > practicality.  Compilers are ill-suited for that scale of computation.
An
>> > external tool would be far better and more practical.
>>
>> Not necessarily.

>If we are currently complaining about the efficiency of 50 elements, then
yes,
>10,000 elements *is* going way beyond real world practicality.

This depends on the compiler. Typically, current compilers don't perform
very well with metaprogramming. But there's no reason that it couldn't be
made more efficient.

>> What kind of subset of core facilities would you like, then?

>The STL is built on top of the built in constructs of the C++ language
itself.
>A core metaprogramming library has to _implement_ those features.

Not necessarily. As has been pointed out by Aleksey, since this is
implemented using functional programming (metaprogramming), there may be
constructs that are more easy to make, and in this context more appropriate
to use for this reason. Therefore, iter_fold, a typical functional
algorithm, rather than something like for/for_each, is used to implement
many of the algorithms.

Even though you might implement much of run-time C++ in terms of MP, it
isn't given that combining those fundamental constructs, to form programs,
is the best way, in a functional world like C++ MP.

It may well be that constructing other algorithms in terms of counterparts
to typical iterative/mutating run-time algorithms, ends up being _more_
complex, than if you used facilities that may be more easily expressed using
FP.

There are also if_, etc. in MPL, and I think it could have much more of such
control structures (like switch-case). However, as said above, it's not
given that implementing these, and using these as building blocks, will lead
to less complexity than the current system. It may be the other way around.
By having high-level algorithms like the STL counterparts, you're free to do
e.g. a functional implementation of them, such as using iter_fold.

Of course, you could have both STL algorithms, and counterparts to run-time
constructs. However, having only the run-time counterparts, may miss out
some opportunities of things that are more easily to express functionally,
but which have no fundamental run-time counterpart, such as the mentioned
algorithm.

>In that
>sense, the MPL is like the definition of C++ combined with the STL.  This
is not
>a really big deal to me, but I do think that the core facilities are
important
>as separate constructs.  This type of separation, with metaprogramming
libraries
>built in levels, makes maintenance much easier and comprehension much
higher.

I understand what you mean, but like I said, there may be easier ways of
doing things, than building directly on those run-time counterparts, since
they assume properties not found in MP, such as iteration, mutability, and
side effects.

Regards,

Terje