Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-15 00:50:48

----- Original Message -----
From: "David B. Held" <dheld_at_[hidden]>

> On the sequence abstraction, I have these comments:
>
> Paul's objections summarized in convenient bullet points:
> > 1) it implies less template instantiation,
>
> It seems to me that this is a premature optimization.  If someone said:
> "I tried to use MPL, but ran out of template instantiation depth!", then
> this would be a valid concern.  Also, it seems likely that instantiation
> depths will get bigger as compiler vendors realize that this is an
> important resource.

It isn't just template instantiation depth.  It is also just plain number of
template instantiations--the iterators for instance.  I agree this is not a big
deal if the performance result is neglible however.

> > 2) is a simpler implementation to maintain and use,
>
> I think this point must be supported with concrete evidence.  The
> maintainability is primariliy Alexsey's problem, isn't it?  He doesn't
> seem to think it's unjustifiably more expensive to maintain.  And I
> fail to see how the usage would be significantly different.  In fact,
> I don't see how it would be different at all.  Examples, please?

[...]

> // Proposed MPL usage?
> typedef copy<
>       range_c<int,10,20>
>     , numbers
>     , push_back<_,_>
>     >::type result;
>
> Pardon my ignorance, but how is the hard-coded sequence type
> "simpler to use"?

How about:

typedef range<10, 20>::type result;

or

typedef append<
      numbers
    , range<10, 20>::type
    >::type result

> > 3) isn't overly generic for no reason.
>
> The following reasons have been given for MPL's genericity:
>
> A) Works with multiple MPL sequence types

Obviously it works, the question is whether its necessary.

> B) Works with foreign sequence types

This is by far the best argument that I've heard, because it actually has some
validity.  I disagree with this reason only philosophically.  I don't think that
we need to encourage reimplementation of the same type of thing.

> C) Works with non-sequence types

Such as what?  The examples given are not general purpose.  For instance, a
random number generator or maybe a list of primes?  If something like that was
actually needed, it would be easy to put them into some standard type container.

> I would like to add another reason that I think is very important (and I
> seem to recall being made long ago, in an earlier discussion, so it
> shouldn't even be a new point):
>
> D) Works with non-type metavalue sequence types

What do you mean by "non-type metavalue"?

> And here are the rebuttals:
>
> A) multiple sequence types are not necessary or convenient.
>
> I think a vector and a tree are sufficiently different to justify the
> existence
> of both in a library.  While MPL does not have a native tree type, there's
> no reason that I can see why one could not be added.  There have
> already been uses mentioned for such a sequence.

I agree that trees have valid uses, and that they should be part of the MPL.
However, trees are not sequences, and when you flatten a tree into a sequence
you lose the utitility of the majority of the algorithms.  Of the remaining
algorithms, it would be far better to specialize the algorithm for the tree.

> B) foreign sequence types can be adapted with a convertor
>
> This is true, but is somewhat like the STL only offering vectors, and
> then demanding that users transfer their data from their own containers
> into an STL vector and back.  Am I mistaken, or does this conversion
> result in a lot more template instantiations? ;)

No, it isn't like the STL with only vectors.  There are valid performance
reasons why multiple sequences are used at runtime.  This justifies the iterator
design of the STL, but not the MPL.  And yes, it likely would result in more
(but not a lot more) instantiations to use a convertor.  However, the point is
that the necessity of using a convertor is very minimal.

> C) non-sequence types aren't important
>
> Technically, anything produced by a generator can be put into a
> sequence and manipulated as a sequence.  So really, this feature
> is mostly syntactic sugar. ;)  But hey, a library as heavy as MPL can
> use all the sugar it can get. ;)

I never said that they aren't important.  I said that they aren't commonly used
enough to justify the abstraction.  In the case of the STL, other things (such
as container tradeoffs) justify the abstraction already, and other things just
happen to work good in that abstraction.  I'm not saying that it can't be done a
compile time; I'm saying that the abstraction is not justified by a few oddball
things like this.

> D) no comment
>
> Again, the non-type sequences (range_c, vector_c, etc.) are mostly
> just syntactic sugar.  However, compared to the "bitter" forms, they look
> pretty sweet.  I don't rightly know whether a single-sequence solution
> could handle vector_c without a converter or not, but if it couldn't, I
> would
> think that these sequences alone (vector and vector_c) would justify
> abstracting the sequence type.

> And, of course, MPL's support for arithmetic and logical metafunctions
> is part of what makes it such a powerful and complete library.  Its
> support of non-type metavalues as first-class citizens seems undeniably
> useful to me.

This stuff I don't have a major argument against.  You can use them or not, but
you have to use the sequence abstraction if you're going to use sequences of
types.

Paul Mensonides