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