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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-14 17:43:29

Andrei Alexandrescu wrote:
> > 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);
>
> I believe this is not a reasonable comparison.

I think it's a very reasonable comparison. It demonstrates the criteria you
used to argue that "C++ only" recursive 'count_if' is "simpler" than
something that uses library-defined primitives.

> The STL does make life
> simpler to the programmers, otherwise they wouldn't use it.

So, I suppose, you, having never used the library, believe that MPL doesn't
make life simpler to meta-programmers? I think that's pretty assumptious,
given that several people on this list testified that they use(d) the
library in the real world and that they do find it useful.

> This whole parallel of MPL with STL is, in my opinion, unfounded.

"The MPL is heavily influenced by its run-time equivalent - the Standard
Template Library (STL), a part of the C++ standard library. Like the STL, it
defines an open conceptual and implementation framework which can serve as a
foundation for future contributions in the domain. The library's fundamental
concepts and idioms enable the user to focus on solutions without navigating
the universe of possible ad-hoc approaches to a given metaprogramming
problem, even if no actual MPL code is used."

Which of the above sentences is false? Or the above is not enough to draw
the parallel?

>
> > 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.
>
> (I'm not sure what optimization - perhaps optimization of compilation
> times? )

And other compilation resources (e.g. number of recursive nested template
instantiations).

> But we are talking about completely different things. STL does help,
> does simplify, does improve.

And so does the MPL, and it's demonstrated in our paper.

> Without doubling your source code size
> and making it incomprehensible.

The first statement is unfounded (in both directions - STL can easily double
your code size, and in general MPL does not), and the latter is your
personal opinion.

[snip]

> This being said, it is a surprise to me that there's no consensus that
> MPL's find_if is much more complicated than the version I posted. To
> me it is obvious. It is so obvious, that I thought there's going to be
> no discussion about it. I thought the argument in MPL's favor is that
> it makes complicated things simple.

It also makes the simple things simple. We just have different definitions
of "simple". I don't agree with yours.

> A convincing argument would be:
> "Well, I agree that count_if is big and hairy,

I do _not_ think so. I think it's conceptualy simple and elegant, and it
could be made even simpler by using the lambda facility, if portability was
not an important goal. I can explain it to anyone who is familiar with
'std::accumulate' in 2 minutes. Given your version, I would spend 10 minutes
on explanation of what is the "cons" structure, where it came from, why type
list is implemented this way, how to iterate through the list using
recursion and class template patterns matching, and how convert an iterative
algorithm into recursive one - and all of these is about the things I don't
even consider relevant to the task being solved. It's like teaching how to
allocate arrays on heap to the person who just needs 'std::vector'.

> and can't be understood but by an MPL savvy, but look,
> here's a nice example of MPL solving a real, hard
> problem, in a very cool manner! How about that?" So it
> seems like we can't find agreement on the simplest premises.

Sad, but true.

Aleksey