RE: [boost] Re: Preprocessor question

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-02-18 04:18:56

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Arkadiy Vertleyb

> I guess I need to provide the context :-)
> 
> I have a macro parameter that describes parameters of a 
> template.  This macro parameter can come in one of two 
> flavours, for example:
> 
> 1) (class)(unsigned int)(bool)
> 
> 2) a number.  This means that the template has n type parameters.
> 
> I want to apply some "magic" to this macro parameter, that:
> 
> - in case 1 would not affect it;
> - in case 2 convert it to something like (class)(class)(class)

This will work on most compilers (including VC)...

#include <boost/preprocessor/control/iif.hpp>
#include <boost/preprocessor/detail/is_unary.hpp>
#include <boost/preprocessor/repetition/repeat.hpp>
#include <boost/preprocessor/tuple/eat.hpp>

#define TRANSLATE(x) \
    BOOST_PP_IIF( \
        BOOST_PP_IS_UNARY(x), \
        x BOOST_PP_TUPLE_EAT(3), BOOST_PP_REPEAT \
    )(x, TRANSLATE_2, ~) \
    /**/
#define TRANSLATE_2(z, n, _) (class)

TRANSLATE( (class)(unsigned)(bool) )
  // --> (class)(unsigned)(bool)

TRANSLATE( 3 )
  // --> (class)(class)(class)

This will work on most preprocessors, but not on those that use the Borland
configuration.  Thanks to Daniel James, I do have a workaround for that bug for
Borland in particular, but I don't have verification that it works on other
preprocessors that use that configuration (so it has to wait until I can
separate the implementations).

> My first attempt was to paste something on the left, like:
> 
> #define DO(x) BOOST_PP_CAT(STEP1, x)
> #define STEP1(x) (x)
> #define STEP11 (class)
> #define STEP12 (class)(class)
> ...
> 
> To naive -- can't paste anything to '('  :-((

Yep (unfortunately--making this defined behavior as a no-op or a retokenization
is on my wish list for a variety of reasons).

> By the way, VC7 did allow me to do this -- this approach 
> worked there.  It is GCC who complained (Not that this is 
> good about VC71.  If you disregard PP, the VC71 is pretty 
> good IMO, but far too tolerant).

Yes.  I was merely releasing some frustration.  VC has gotten significantly
better in all other areas (with the notably exception, IMO, of everything
related to managed code).

Regards,
Paul Mensonides