Boost logo

Boost :

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-19 11:49:25


The practical portability is quite good - at least I haven't yet run into
major problems. I've tested or used these macros on multiple compilers (MSVC
(5.0 / 6.0 / 7.0 beta (X-Box)) and MWCW (Dreamcast, Palm, PC), DEC CXX and
G++). There are a few differences between the preprocessors of different
compilers, which I've unfortunately not recorded/analyzed very carefully,
but generally they are quite portable. I recall running into some
differences while porting code from MSVC to other compilers. If I remember
correctly, the MSVC compiler behaved slightly differently from the standard,
which allowed some buggy code to actually generate the desired results on a
few occasions.

The limits are compiler dependent and generally depend on both recursion
depth and size of the generated code, so it is fairly difficult to give any
numbers. On a particular code the MSVC preprocessor managed recursion depth
of approximately 250 whereas MWCW did only approximately 120. On a
particularly lengthy macro (a brute force taylor expansion for sine for
calculating a sine look up table), I recall seeing limits of only 30-60
recursions on MWCW 7.0 for Palm. In practise, I would estimate that the
technique is safe for use up to lengths of at least 63 as long as the code
is not too long or recursive. Most plausible uses actually fall into this
category. It is often possible to use REPT(n,E), which due to its simpler
implementation, is safer.

Obviously, more rigorous testing would be in order, before adopting wide
spread use.

I'm not familiar with the boost::function library. The name reminds me of a
functional programming library. For generating function arguments, the list
primitive should be safe enough for production use, because the recursion
depth is rarely over 30. BTW: It is possible to implement generalized
binding (i.e. bind<ith_arg>(fun_with_n_args, bound) in O(1) tokens using
this technique, which gets expanded to O(n) tokens for the binding code and
O(n*n) tokens for the actual function calls. The basic idea is to use tuples
and default arguments to avoid code repetition.

There are a few more CPP technique that can be useful sometimes, although
they can often be largely obsoleted by using techniques such as PLA/layering
or the Barton-Nackman trick (especially the algebraic categories). One of
such techniques is to define a look up function. For example:

    #define LOGIC_OP(i) CAT(LOGIC_OP_,i)
    #define LOGIC_OP_0 <
    #define LOGIC_OP_1 <=
    #define LOGIC_OP_2 >
    #define LOGIC_OP_3 >=
    #define LOGIC_OP_4 ==
    #define LOGIC_OP_5 !=
    #define LOGIC_OP_CNT 6

    #define LOGIC_OP_MNEMO(i) CAT(LOGIC_OP_MNEMO_,i)
    #define LOGIC_OP_MNEMO_0 Less
    #define LOGIC_OP_MNEMO_1 Less_Equal
    #define LOGIC_OP_MNEMO_2 Greater
    #define LOGIC_OP_MNEMO_3 Greater_Equal
    #define LOGIC_OP_MNEMO_4 Equal
    #define LOGIC_OP_MNEMO_5 Not_Equal
    #define LOGIC_OP_MNEMO_CNT 6

A look up function can then be used in the ELEMENT parameter to generate
code using the LST or REPT macros.

    #define DEF_COMPARATOR(i) \
     struct LOGIC_OP_MNEMO(i) \
     { \
      template<int x, int y> \
      struct Code \
      { \
       enum \
       { \
        ret = x LOGIC_OP(i) y \
       }; \
      }; \
     };

    REPT(LOGIC_OP_CNT, DEF_COMPARATOR)
    #undef DEF_COMPARATOR

I will post a listing of my findings on CPP meta programming as soon as I
have finished writing it.

----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, May 19, 2001 18:25
Subject: Re: [boost] Interest in CPP meta programming library?

> On Saturday 19 May 2001 10:16 am, you wrote:
> > Hi,
> >
> > I'm thinking of submitting a small CPP or C Pre Processor meta
programming
> > library into Boost. For this reason I have uploaded a trivial demo
subset
> > of the library into the Files section/Vault. You can find the files
under
> > the CPP folder. The rest of this message contains a motivated example of
> > the use of a particular feature of the library.
>
> <drool>
>
> I am most definitely interested in this. The boost::function library has
huge
> amounts of generated code and maintainence on the Perl script that
generatess
> it has become a nightmare.
>
> I'm interested about the practical portability of such a library. Does it
> generally work well across compilers? What sort of limitations have you
run
> into? Macro expansion depth limitations? Macro length limitations?
>
> Doug
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk