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