Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-11 13:37:58

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

> > It isn't really an iterator.  In this sense, it is just a typedef.  The
> analogy
> > to iterators only applies in the presence of multiple sequence types.
>
> Well, the implementation of iterator, for cons-lists, is very much like a
> cons-list, in itself, in MPL. You can map it to cons, with "type" being
> "head" and "next" being "tail". That's what I meant.

In a sense, typedefs are just compile-time pointers to actual types.  In that
sense, they can act like iterators.

> > This is still an open question:  Can you give me one non-contrived example
> that
> > demonstrates that a vector-like sequence is faster than a cons-like
> sequence
> > *and* vice versa?
>

Thanks for the tests.  It seems that, as predicted, vectors are faster than
lists.

> --- End ---
>
> Even though vector performs faster, here, there are other issues with
> vector, such as it being fixed maximum length, or requiring the use of the
> preprocessor to increase this length. This may be expensive.

There is also a maximum length of list also.  The difference is that is a
limitation of a particular implementation rather than a limitation of the source
code itself.

> > All that I ask is for one realistic example that shows a worthwhile
> increase in
> > speed using one sequence vs. another and vice versa.
>
> As mentioned above, speed is not the only issue.

Apparently, the speed difference is negligible on small sequences that the
vector can hold.  It only starts really improving compile-times when you go
beyond what the vector can hold as is.  Of course, this doesn't surprise me at
all.

My synopsis of this is that vectors are superior for large sequences that are
unrealistic to implement (w/o the preprocessor <- which adds its own time), and
the speed difference is neglible otherwise.  The limits are still there with
lists they are just buried in the compiler and possibly compiler switches.

The only real difference that I see is syntactic.

> > I agree with this as far as pure metaprogramming goes, and I like this
> aspect of
> > the STL.  It is a different situation when you are using metaprogramming
> to
> > facilitate real code.
>
> In what way could the use of template template parameters, rather than
> classes with member templates, be of help here, you mean?

When mixing metaprogramming into normal code.  For instance binding a certain
template with too many elements to a template parameter, etc.

> > A template-template binding and deduction mechanism would
> > be useful for such a thing.  Also, if we don't use it, it is not likely to
> get
> > improved. :)
>
> I understand what you mean. I think Andrei has proposed, for template
> template parameters, something like "template Function", rather than the
> current syntax "template<class> class Function", so that it wouldn't be
> restricted to a certain arity.
>
> However, this would still mean you couldn't mix it with types, as you can
> now, using types, with member templates.

At some point, it comes down to the actual types, values, or "template
templates"--as demonstrated by the multiplies example that you had.  At some
level, you have to do that.  You can't get around the differences totally; you
can only delay the point at which they have to be handled specifically.

> > > It seems we agree on the complexity of passign templates around, in the
> > > general case. If you don't wrap them up, it will simply collide all over
> the
> > > place. You won't be able to treat metafunctions as first-class citicens,
> and
> > > I think such uniform, generic treatment is key to its power. It lets you
> > > relatively easily transform metafunctions, store them, pass them around,
> > > etc.
> >
> > I don't disagree with the utility of this abstraction.  However, I do
> disagree
> > with this reason for it.  You can easily encode any of the above into a
> type at
> > will.  What that engenders is a simple subset with more elaborate designs
> built
> > on top of it.
>
> I don't think I understood you, here. The question was using templates vs
> using classes with member templates. Could you try to explain, or give an
> example?

I don't think they would collide all over the place.  However, I'm not
advocating the necessary tools to solve that problem.  It isn't worth it.  I
like this part of the MPL's abstraction, but I do think that we need this type
of stuff for a true metaprogramming library at some point.

Paul Mensonides