-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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