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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-14 19:24:59

Andrei Alexandrescu wrote:
> > FWIW, IMO, Aleksey is right here, and people who don't understand
> > the purpose of higher order sequence manipulation functions should
> > really read some book on functional programming.
>
> Higher order sequence manipulation functions are indeed important.
>
> Where I think otherwise is the simplicity argument.
>
> IMHO, understanding matching for template arguments in the context of
> C++ does not ask for a functional programming background. It asks for
> C++ background. Template arguments are matched to template parameters,
> and this is a fact of C++. This C++ feature can be useful in a number
> of contexts.

Dynamic arrary allocation is a C++ feature that can be useful in a number of
contexts as well - in particular, while implementing STL containers. It
doesn't mean though that now one have to write 'int* p = new int[n]' every
time she needs a variable-sized container.

> My argument on the simplicity of the pattern-matching implementation
> of count_if is NOT based on the assumption that people with functional
> programming background would be comfortable with it. (I am not much of
> a functional programmer myself.)
>
> The implementation of count_if as a library artifact is largely
> irrelevant. As long as a library function respects an interface, the
> library user can only appreciate a more sophisticated implementation.
> I understand we are discussing count_if as an example of typical
> implementation of a user-defined algorithm.

A user-defined algorithm that "conforms" to the library's conceptual
framework can be written in a variety of styles, depending on the user's
needs and preferences. The version of 'count_if' I posted is how the library
itself implements the algorithm. A Peter Dimov's implementation is another
possibility, and the lambda-based version
(http://lists.boost.org/MailArchives/boost/msg28275.php) is the third one.

>
> Again, let me post some simple measurements of the two variants of
> count_if.
>
> The count_if implementation using mpl has 34 lines, defines 3 new
> types, 1 new namespace, and relies on 5 artifacts defined elsewhere.
>
> 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.
>
> This being said, my argument on the simplicity of the pattern-matching
> implementation of count_if is based on the following points:
>
> 1. Show the sheer code to a C++ programmer. For completeness' sake, I
> appended the code at the end of this post.
>
> 2. 15 < 34
>
> 3. 1 < 3
>
> 4. 0 < 1
>
> 5. 1 < 5

I beleive I addressed this comparison in my previous replies.

>
> Several people have repeatedly asked for self-contained, sensical
> examples demonstrating that using the style pioneered by MPL leads to
> a good solution. I believe this is reasonable to ask for.

First of all, I believe that 'count_if' implementation _is_ an example when
"MPL style" leads to a better solution than what you've been citing as a
"simpler" way.

Secondly, some of such examples were posted as early as 4 month ago. In
particular, Mat Marcus have shown how implement Loki's 'GenLinearHierarchy'
using MPL facilities - in one line of actual code:

    template< typename Types, typename Unit, typename Root = mpl::none >
    struct gen_linear_hierarchy
    {
        typedef typename mpl::fold<Types,Unit,Root>::type type; // here
    };

/* usage example:
    template< class Base, class T >
    struct EventHander : public Base
    {
        virtual void OnEvent(T& obj, int eventID) = 0;
    };

    typedef gen_linear_hierarchy<
          mpl::list<Window,Button,ScrollBar>
        , EventHander<_1,_2>
        >::type v;
*/

Thirdly, our "largest" example in the paper clearly demonstrates the
advantages of the "MPL way".

For some reason, ignoring the provided input and asking the questions that
already have been answered again and again seems to be an unfortunate
pattern of this thread.

Aleksey