RE: [boost] MPL containers and algorithms

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-29 21:33:11

Andrei Alexandrescu wrote:
> As a consequence of supporting multiple containers, 
> algorithms are more complicated and contorted in 
> both interface and implementation.

Ignoring the part of the statement about implementation for a moment, care
to cite an example of interface "contortion"?

> So far, however, I haven't seen any piece of evidence on why 
> a variety of type containers would be needed instead of dot-lists.

'range_c' and 'vector' are not enough for you?

BTW, I am kind of tired of repeating the same arguments over and over. If
you don't agree with them, it's your right. The separation of algorithms
from the sequence implementations is one of these things in MPL design that
are not going to change, period. I think it has been argumented well enough
over the time; if you feel that this is a corner issue, feel free to vote
the library down.

> Dot-lists satisfy the closure property (can represent any data structure),

So how your ideal "dot-list" sequence looks like?

> and are 
> easiest and most natural to manipulate with C++'s template engine.

They are certainly not. It's at least as easy to write an algorithm using
[forward] iterators as it is for a particular "dot-list" sequence:

    template< typename Iter, typename End >
    struct size
    {
        enum { value = 1 + size< typename Iter::next, End >::value };
    };

    template< typename End >
    struct size<End,End>
    {
        enum { value = 0 };
    };

> 
> An argument that was aired is that various compile-time 
> structures would lead to different compile times. 

Most certainly, especially if you consider random access to the sequence
elements.

> Consequently, the argument goes, the developer would 
> select the structure that leads to the least memory occupied 
> and the fastest compile time. However, experience shows 
> that various compilers prefer various data structures, depending 
> on how the compilers implement templates. 

Not particularly true. The times do wary, but the big picture is the same
regardless the compiler - in particular, it's guaranteed that random access
to the sequence is at least as fast as the linear one, and in practice it's
always faster - even on Metrowerks.

> So if one is to write portable code, there is no clear choice 
> of a structure over another.

Not true, see the above. The choice is determined by the algorithm(s) you
want to implement/apply, and the typical size of the data being processed,
in the similar way it's done in run-time STL world.

Aleksey