Re: [boost] [preprocessor] undef file iteration includeguard?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-09-02 06:10:14

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Larry Evans

> The 01.09.2006 04:12 ctor_template.zip file in the vault is 
> my attempt at doing what you've outlined above.  BTW, instead 
> of something like the G macro, it uses:
> 
>   g( BOOST_FWD_SEQ_FOR_EACH_IDENTITY
>      ( (x)
>        (y)
>      )
>    )
> 
> Please let me know if you see any errors.

You can do it a little more efficiently regarding the comma handling.  E.g.

#define SEQ_FOR_EACH_IDENTITY(seq) \
    BOOST_PP_SEQ_FOR_EACH_I(APPLY_IDENTITY, ~, seq) \
    /**/
#define APPLY_IDENTITY(r, _, i, x) \
    BOOST_PP_COMMA_IF(i) boost::forwarder::identity(x) \
    /**/

You could also let the pp-lib do the work:

#define APPLY_IDENTITY(s, _, x) boost::forwarder::identity(x)
#define SEQ_FOR_EACH_IDENTITY(seq) \
    BOOST_PP_SEQ_ENUM( \
        BOOST_PP_SEQ_TRANSFORM(APPLY_IDENTITY, ~, seq) \
    ) \
    /**/

Either way, the speed difference between the above two is neglible for the
number of arguments we're talking about (I tested up to 50).

> The newest zip also includes a Makefile which I've found 
> useful in seeing what's produced by cpp.  I was wondering how 
> you've gotten bjam to do something similar to that Makefile.  
> If so, could you post the code or a link?

I don't use bjam for this.  I run the compiler (or a set of compilers) in
preprocess-only mode and look at the output.

I make small proof-of-concept scenarios (regular code) in order to establish
what I want to generate.  Once I have decided that, then I write the generator
and debug any errors I might have made.  At this point, I'm specifically testing
the generator--not the generated code.  Once I'm satisfied that the generator is
generating what I want, I then go on to full compiles and debugging the
generated code.  When I'm writing and testing the generator, I either do it
outside of a normal "heavyweight" translation unit, or I comment out header
inclusions that are not necessary for the generator itself--namely so I don't
have to wade through enormous amounts of output to find my generated code.  E.g.
say I'm generating something that uses std::cout, when I'm writing and testing
the generator, I'll comment out the inclusion of <iostream> because the
generator itself doesn't need it to function.

On most compilers, the preprocess-only command line switch is -E.  Several
compilers also support a -P command line switch that suppresses #line directives
in the output and generally compacts vertical space.

Regards,
Paul Mensonides