Re: [boost] Preprocessor: documentation comment

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-16 14:28:07

> Many of the recent changes cause compilation slowdown, because the new
> macros are not yet optimized, but this should change in the future.

In the case of 'automatic recursion', it will always be more inefficient then
directly invoking the macro though.

> Preprocessor metaprogramming is very much like programming in a strict,
> purely functional programming language. This will be even more true once the
> new techniques will be fully incorporated and the user doesn't have to pay
> so much attention to preprocessor limitations.

Agreed.  It is also worthwhile to point out that the preprocessor operates on
extreme lazy evaluation as well.  That can be both a help and a hinderance.

> The preprocessor library should not degenerate into a collection of special
> case macros for special cases encountered by C++ programmers. Instead the
> preprocessor library should make it significantly easier to build
> application specific macros for the special cases needed by the application
> developers. Of course, the library should and does offer some support for
> C++ language constructs.
>
> -Vesa

I wouldn't call basic C++ constructs 'special cases'.  There are various parts
of C++ that are by definition lists--parameter lists, template argument lists,
etc..  Those things I wouldn't call special cases.  A special case is something
like Dave's 'argument handling' lists in 'returning.hpp' in his Python library.

For example: (from the pre-expanded 'returning_void.hpp')

template<class P, class A0, class A1, class A2>
    // -----------^ this is *not* special case
static PyObject* call(
    R (A0::*pmf)(A1, A2),
    // ----------^ this is *not* special case either
    // in fact, I go so far as to say the entire pointer-to-member
    // is not special case
    PyObject* args_, PyObject*, P const* policies)
{
    arg_from_python<A0&> c0(PyTuple_GET_ITEM(args_, 0));
    if (!c0.convertible()) return 0;

    arg_from_python<A1> c1(PyTuple_GET_ITEM(args_, 1));
    if(!c1.convertible()) return 0;

    arg_from_python<A2> c2(PyTuple_GET_ITEM(args_, 2));
    if(!c2.convertible()) return 0;

    // the 'list' above, starting with A1, *is* special case

    if(!policies->precall(args_))return 0;
    ((
        c0(PyTuple_GET_ITEM(args_, 0))).*pmf)(
            c1(PyTuple_GET_ITEM(args_, 1))
            ,c2(PyTuple_GET_ITEM(args_, 2)));
    // -----^ this is also special case
    return policies->postcall(args_,detail::none());
}

Also, I wouldn't say that it would degenerate because of that.  The primitives
that I'm talking about would just be common 'shells' on top of the existing
mechanism.  These are things that are extremely common uses--not special cases.
After all, it doesn't need just functionality to make it a metaprogramming
language--it needs functionality to make it a 'C/C++ metaprogramming language'.
We cannot forget the end goal--a metaprogramming environment *for C/C++*.

Paul Mensonides