Re: [boost] [preprocessor]undef file iteration include guard?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2006-08-31 00:09:09

On 08/30/2006 05:18 AM, Paul Mensonides wrote:
[snip]

> normal one), as it is *intended* to be included multiple times.
> Also, it is using what the pp-lib calls "named external arguments",
> which, for all intents and purposes are arguments to the "function
> call".  The header should #undef those macros:

> // boost/forwarder/ctor_template.hpp
> #if BOOST_PP_IS_ITERATING
> 
>     // ----- point 1 ----- //
> 
>     // "include guard" (to save time)
>     #ifndef BOOST_FORWARD_CTOR_TEMPLATE_INCLUDED
>     #define BOOST_FORWARD_CTOR_TEMPLATE_INCLUDED
>         #include <boost/preprocessor/iterate.hpp>
>         #include <boost/preprocessor/repetition/enum_binary_params.hpp>
>         #include <boost/preprocessor/repetition/enum_params.hpp>
>     #endif

Ah!  This is where I went wrong.  The ctor_template.hpp file was my
modification of the SEGMENTED_FUSION_V2
file:

  http://tinyurl.com/zgxho
  
which had the #include-guard guarding the complete then branch of the 
#if BOOST_PP_IS_ITERATING.  Your above comment:

  // boost/forwarder/ctor_template.hpp

makes clear the purpose of the #include-guard.  I'd failed to
understand the purpose of the #include-guard (somehow I'd figured it
was needed for the boost-pp file-iteration to work).

[snip]
> After this, the client code looks like:
> 
> #include <boost/forwarder/ctor_template.hpp>
> #include <boost/preprocessor/repetition/enum_params.hpp>
> 
> // ...
> 
> #define BOOST_FORWARDER_CTOR_TEMPLATE_THIS_TYPE sub
> #define BOOST_FORWARDER_CTOR_TEMPLATE_BASE_TYPE(n) :
> Super(BOOST_PP_ENUM_PARAMS(n, _))
> #include BOOST_FORWARDER_CTOR_TEMPLATE()

Great!  I've followed your suggestions and the code works.  The
modified code was uploaded to the same place in the vault.
I've also corrected the minor problems you noted in your first reply.

[snip]

> BOOST_PP_IS_ITERATING.  What the file-iteration mechanism is
> basically doing is defining a for-loop mechanism that calls a
> user-defined function:

> namespace boost { namespace preprocessor {
>     bool is_iterating;
> 
>     template<class F> void iterate(int a, int z, F func) {
>         is_iterating = true;
>         for (; a <= z; ++a) {
>             func(a);
>         }
>         is_iterating = false;
>         return;
>     }
> }}

> The "ctor_template.hpp" header (as it currently exists) is such a
> function, but its initial call (the one that starts the iteration)
> is done by the client, not the file-iteration mechanism.  You have
> to write that file as if it is a function--not a header.  But you
> should also provide a normal header that defines the interface to
> the function (i.e. BOOST_FORWARDER_CTOR_TEMPLATE()) and includes the
> files needed by the function.
 
> Make sense?

Yes.  Makes much better sense to me now.  Thanks Paul :)

-regards,
Larry