RE: [boost] preprocessor fix

From: Arias Brent-P96059 (Brent.Arias_at_[hidden])
Date: 2004-11-23 13:13:21

>  Have you seen
http://www.cuj.com/documents/s=8470/cujboost0306besser/?  

Yes, I have seen that before.  I did not use it for several reasons: (1) I think the source for Besser's ENUM was not easily available, (2) my employer gets nervous when code "looks" too C++ oriented and gets nervous when macros become too "involved" - which means "lengthy" (3) Besser's ENUMX macro requires that you specify the number of parameters (e.g. ENUM3 or ENUM23).

Reason #3 was a real hurdle for me - because I'm trying to provide this macro to other developers who might "rebel" if using the macro requires from them non-intuitive new concepts or exercises.  That is, if they didn't have to count the number of parameters in the enumeration before - they may well reject the ENUM macro if it starts to require them to count the entries.

So, I set out to make an ENUM macro that (1) didn't need its entries counted by the developer and (2) had a short definition (which makes it less daunting for "managment" buy-in).

You said:

>there are still basic notions of computation, etc., such as
>control flow--which is nothing but a conditional "invocation"
>of its accompanying code.  Those kinds of things still apply
>at the preprocessor level.  What you really needed was a way to
>conditionally enumerate some sequence elements, not enumerate a
>conditional sequence.

My implementation was "backwards" because I was unable to make the code compile otherwise.  That is, depending on the value of ENUMS, the following code did not compile:

> #define ENUM(name, start, entries) \
>     BOOST_PP_EXPR_IIF(ENUMS)( \
>         BOOST_PP_SEQ_ENUM( \
>             (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \
>             BOOST_PP_SEQ_TAIL(entries) \
>             (LAST_ ## name } name;) \
>         ) \
>     ) \

You said:

>You can do it, but EXPR_IIF does not lazily evaluate its
> argument (the syntax above is what EXPR_IIF would look
> like if it *did* lazily evaluate it argument).
>In other words, when ENUMS is 0, SEQ_ENUM will still be 
>invoked, but its results will be discarded.

I'm not sure what you are suggesting.  Depending on the value of ENUMS, the code snippet I showed above would not compile - lazy evaluation or not.  If it won't compile, then there's nothing for me to ponder (except to use a different approach - which happily you taught me with the TUPLE_EAT macro).  :)

Paul, thanks so much for the help you've provided.

-Brent