Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-11 14:02:23

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

> > Also, a newcomer has an easier learning curve to template metaprogramming
> and
> > how it works in the general sense--rather than the use of a specific
> > library--Loki or the MPL.
>
> By all means, learning how it works is useful, too. However, I don't think
> we should repeat the mistake that some C++ teachers do, to teach C++ the way
> themselves learned it, going the C-first way, if there there turns out to be
> a better way of learning it, learning C++ as a high-level language, by
> _starting_ with using the library, rather than having that towards the end
> of the book, as is often common.

I don't think that you can say unilaterally that learning C++ with the "C
subset" is a mistake.  Doing that presents dangers, yes, but so does teaching
high-level functionality first.  Any one that is commited to actually learning
C++ will learn it fine either way.

> I learned C before C++, too, and I used to think it was the best way. I
> don't, anymore. The authors of "Accelerated C++" also have experience with
> both ways of teaching it.

Yes, and we also have the results of the high-level style of teaching as well.
Lots of programmers can put pieces together, but not enough of them know what is
actually going on--even in a general sense.  They don't understand the actual
way that computers work or any of the low-level details.

> The same may go for metaprogramming. I also learned the template
> specialisation, pattern-matching way first. Much of what I know about
> metaprogramming, especially the practical application of it, I've learned
> from "Modern C++ Design". So that certainly has much credit for it.
>
> Similarly, it may be better to learn metaprogramming, by using a library for
> it, rather than starting with writing your own components.

Of course, I was simply saying that using a library will only help you 1) do
what the library already does and 2) learn metaprogramming concepts and techniqu
es.  If the library fails to do that later, than you are ill-equipped to extend
the library or make your own constructs.

> > > > In fact, MPL code resembles more run-time code, than Loki's typelists,
> > > which
> > > > means that you can use your experience with such code, when using it.
> > >
> > > Agreed.
> >
> > Agreed as well, _however_ template metaprogramming is a different
> environment
> > altogether.  You are simply hiding the natural way that environment works
> with
> > constructs that can only imitate imperative programming.  This is not
> > _completely_ bad, but it does have disadvantages as well.  At some point,
> a user
> > is going to run into the full, actual environment that is template
> > metaprogramming with no analogy to STL to help (i.e. coddle) them along.
>
> The same has been said about using C++ as a high-level language, to advacate
> for teaching the low-level C details first. However, it has been found that
> you _can_ use std::string, the STL, etc. as high-level components, without
> having to learn how they actually work.

Yes, but just like teaching low-level details first, this is a time-bomb waiting
to explode.  I'll go out on a limb here :) and say that for someone who is
actually interested and actively committed to learning C++, it doesn't matter
which way they learn first.  For someone interested only in turning out the
required functionality, what you say is true.  However, I don't really care
about people that don't care to learn C++ fully.

> Yes, you may get some horribly long error messages when using STL, but
> surely, you don't advacate for everyone making their own STL, before they
> can use it? In other words, having to learn how it all works.
>
> In a similar way, you may run into long error messages, when using MPL. So
> what's new?

Nothing, in this regard.

> Yes, if you want to create new components, you need to learn how to do that
> in the framework. That goes for both STL and MPL. However, you may use
> either of them, with some basic understanding of how it works.

Metaprogramming in general (template and preprocessor) by definition exposes too
much of its implementation already.  You can't avoid that completely.  What that
boils down to is that you have to be able to understand the concepts involved
reasonably well in order to really get anything worthwhile done.

> > > I was referring to my post that emphasizes (1) that templates offer a
> > > different computational model than C++'s runtime virtual machine; (2)
> that
> > > we use C++ compile-time programming for different tasks than C++
> run-time
> > > programming.
> >
> > And this is absolutely true.  In fact, the purpose of metaprogramming is
> to
> > complement 'regular' programming in some way or another.  That is
> > metaprogramming's ultimate 'ends'.  For obvious reasons, runtime
> programming is
> > not equivalent.  Nor or the means and ends similar--that doesn't make
> sense. :o)
>
> As mentioned in the previous posting, the basic difference between the two
> is binding time. That's all. The rest is about how it's implemented. For
> run-time programming, the means are the run-time constructs, and for
> compile-time programming, the means are the compile-time constructs. The
> ends may well be the same.

No, binding time is obviously relevant, but the basic difference is not binding
time.  Metaprogramming produces code (in a sense) to be consumed by the regular
code.  That is a big difference.

> > He means, I think, using imperative types of abstractions (such as
> iteration vs.
> > recursion, etc.) in a functional environment.  In a sense he is right.
> _But_ we
> > have decades of experience with imperative and functional languages that
> say one
> > thing or another is not a _natural_ idiom in a functional language.  We
> better
> > be pretty sure of ourselves to throw out the learning gained in the past.
>
> Let's be concrete, what in MPL would be an example of what you say here?
> That is, expressing something that isn't found in FP, and which would be
> different to "traditional" MP.

Iteration vs. recursion for example.  The styles involved in functional
programming are inherently different than imperative programming in many
respects.  Template metaprogramming is functional, therefore the most natural
way to use such a language is with the functional style that has been built over
many years.

> > to the use of multiple sequence types?  IMO, the correlation to the STL
> breaks
> > down at this point.
>
> Sequences is just one thing. Combination of metafunctions, lambda (not found
> it STL, but found in Boost.Lambda), etc. are also similar.

The STL analogy applies specifically to sequences.  I don't mean that the MPL
has stuff that the STL doesn't or vice-versa.  I mean that the fundamental
premise of the STL analogy is flawed with regard to sequences because the actual
reasons for that abstraction in the STL do not apply to template
metaprogramming.  The only thing that you really get out of it is syntactic
sugar and limited similarity to STL code--which is not nearly as strong of an
argument as you tend to make it (IMHO). :)

> > Count me as #4 also.  A good example that demonstrates the utitilty of the
> > sequence abstraction in the MPL would be a significant argument for it.
> In
> > particular, one that shows that vector-like sequences outperform
> cons-style
> > lists *and* vice-versa in different scenarios.
> >
> > To be honest, I seriously doubt that anybody *can* come up with a good
> example.
> > Personally, I think that the vector-style will always be faster and the
> > cons-style always more elegant.
>
> Without considering speed, there's another aspect of vector vs cons-lists
> worth considering. At least the way they are implemented in MPL, you can't
> have vectors longer than the maximum length (50), without using the
> preprocessor, at least. I've tried to have longer vectors, but I got errors
> when trying it (on g++ 2.95.3). Have you got longer vectors to work?

I haven't tried it, no.  But I fully expect that vectors will outperform lists
in every non-pathological case.

> In any case, in MPL this means using the preprocessor, which may be quite
> expensive, certainly on EDG based compilers.

It wouldn't be that bad.  In fact, it could actually be really fast with
file-iteration.

> Cons-lists, on the other hand, have no limit to their length, and don't
> require the preprocessor.

*Theoretically* they have no limit, in actuality they do.

> > I think that many people are infatuated with
> > the analogy to the STL and are thinking that this analogy will prove
> itself down
> > the road (instead of now).  This is an experimental viewpoint, not a
> practical
> > one.  If it doesn't turn out that way (which could *easily* be the case),
> we
> > have brought along a significant amount of implemenation and design
> baggage.
>
> What I said above here, shows that there are issues, already, especially if
> you were to have only vector, as you suggest.

I'll summarize:

The speed advantages are neglible unless large numbers are used, which is
exactly where the vector implementation has *serious* disadvantages.  Syntactic
clarity can be solved easily.  And the size limitation still exists--it is just
transferred to the compiler.

Paul Mensonides