[boost] Re: Re: Adding Loki to Boost (reprise)

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-12 03:36:38

Andrei Alexandrescu wrote:
> > The above implementation is useless for 'tiny_list' (and any type
sequence
> > we use here at work).
>
> It is useful for dot-typelists though, which are the only ones I use.

Sure.

> I think it would be good to find things that are quite easy to do with
mpl,
> and are very hard to do with recursion and dot-lists. My belief is that
for
> many processing needs, dot-lists and recursion are simpler.

If you define "simpler" as a synonym to "uses less ''advanced'' concepts",
then, well, yes. But by that definition

    int* v = new int[100];
    // ...
    int i = 0;
    for (; i < v.size(); ++i)
        if (v[i] == 5) break;

is definitely simpler than this:

    typedef std::vector<int> something;
    // ...
    something v;
    something::iterator i = std::find(v.begin(), v.end(), 5);

Yet you'll have hard time convincing me that when one wants to search a
sequence, she should should prefer the former approach.

>
> As an example, count_if's implementation using mpl has 34 lines, defines 3
> new types, 1 new namespace, and relies on 5 artifacts defined elsewhere.

Reuse of these "artifacts" is the power that allows MPL to be much more
generic and portable; it also enables performance optimizations applied in a
single relatively low-level component to be propagated through the rest of
the library. Arguing against this kind of reuse is like criticizing
'std::vector' implementation that uses '__construct' and '__destroy'
"instead of" bare placement new and explicit loop with destructor call.

> The count-if that works only for dot-typelists has 15 lines, defines 1 new
> type, and does not rely on any other artifacts than the typelist itself.
>
> I believe it is reasonable to say that the latter code for count_if is
> easier to write, read, and understand. If there is claim to the contrary,
> really I cannot bring more argument beyond sheer code and the measurements
> above.

How about the above code snippets? Would you say that the first one is
easier to write, read, and understand? It doesn't define any new types, and
definitely does not rely on any other "artifacts", - not to speak about
"simplicity".

>
> I understand that count_if is more general, so it is entirely acceptable
to
> pay a cost in ease of understanding for the benefit of generality. The
> question is whether that generality is worth the price in complexity. To
me
> it looks like it's not - the type processing needs I have are satisfied by
> dot-lists and simple algorithms such as count_if above.

Well, ours are not.

Aleksey