[boost] Re: MPL containers and algorithms

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-14 17:41:02

"Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
news:38df01c243d6$9e8c6aa0$60fb5dd5_at_pc...
> [...]
> This may not be that easy, using iterators. Trees are inherently
recursive,
> so they are usually much easier to traverse and manipulate, using
> recursive algorithms, than iterative algorithms.
> [...]

Speaking of which, a tree type sequence might be a nice addition to
MPL.

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.

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

Here is what I see:

// Current MPL implementation
template<
      typename Sequence
    , typename State
    , typename BinaryOp
    >
struct copy
{
    typedef unspecified type;
};

// Current MPL usage
typedef copy<
      range_c<int,10,20>
    , numbers
    , push_back<_,_>
    >::type result;

// Proposed MPL implementation
template<
      typename MPL_Vector
    , typename State
    , typename BinaryOp
    >
struct copy
{
    typedef unspecified type;
};

// 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"?

> 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
B) Works with foreign sequence types
C) Works with non-sequence types

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

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.

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? ;)

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

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.

Dave