Re: [Boost-users] Boost preprocessor question

Subject: Re: [Boost-users] Boost preprocessor question
From: Peter Bartlett (pete_at_[hidden])
Date: 2009-01-06 02:49:46

Quoting Michiel Helvensteijn <m.helvensteijn_at_[hidden]>:

> Pete Bartlett wrote:
>
>>> What about:
>>>
>>> CLASS(Foo, FROM(Bar),
>>>    CONSTRUCT(BOOST_PP_EMPTY_SEQ)
>>>    CONSTRUCT((int, a, A)(bool, b, B))
>>>    int A;
>>>    bool B;
>>> )
>>
>>> Might that not be a way to avoid the Foo repetition?
>>
>> It would have to look like
>>
>> CLASS( Foo, FROM(Bar)
>> , CONSTRUCT(  BOOST_PP_EMPTY_SEQ )
>>   CONSTRUCT( (int, a, A)(bool, b, B) )
>> , int A ; bool B ;
>> )
>>
>> where you have
>>
>> #define CONSTRUCT(sequence) sequence

Sorry this should have been

#define CONSTRUCT(sequence) (sequence)

> Why wouldn't my example work?

For each occurence of CONSTRUCT you need to print Foo. The only thing  
that /can/ print Foo is the CLASS macro so you end up with the  
constraint that one of the arguments to the CLASS macro is a sequence  
of CONSTRUCTs so that CLASS can be partially implemented in terms of a  
BOOST_PP_FOR_EACH over that sequence. Your third argument is not a  
sequence, but with the correction mine is.

> You know, I just realized it's not possible after all, since I will also add
> enums and structs as sub-types sometimes. They contain comma's, which would
> break the macro-call. I'll use the END_CLASS notation and accept the Foo
> repetition. :-)

Well, don't underestimate the power of the preprocessor and in  
particular the Boost.Preprocessor library. Appropriate use of  
parentheses can sort out those commas in many cases. And in the harder  
cases, there is also BOOST_PP_COMMA.

Having said that, when the macro design gets this complicated there  
is, in my experience, usually an under-use of templates in the  
underlying code.