Hi, the following code does not compile: #include <boost/preprocessor/if.hpp> #include <boost/preprocessor/comma.hpp> #include <boost/type_traits/is_convertible.hpp> #include <iostream> class A {}; int main(void) { BOOST_PP_IIF(boost::is_convertible<A BOOST_PP_COMMA() A>::value, // condition std::cout << "ifbranch";, // then std::cout << "elsebranch";); // else return 0; } With gcc, it gives the following errors: tst.cc:9:30: error: macro "BOOST_PP_IIF_I" passed 4 arguments, but takes just 3 tst.cc: In function int main(): tst.cc:7: error: BOOST_PP_IIF_I was not declared in this scope I would have expected that BOOST_PP_COMMA() has just been provided to deal with cases like this! I'm just new to Boost, so my apologies if I have overseen something obvious. Thanks for any help, Christof
Quoting "Warlich, Christof \(Christof\)" <cwarlich@alcatel-lucent.com>:
Hi,
the following code does not compile:
#include <boost/preprocessor/if.hpp> #include <boost/preprocessor/comma.hpp> #include <boost/type_traits/is_convertible.hpp> #include <iostream> class A {}; int main(void) { BOOST_PP_IIF(boost::is_convertible<A BOOST_PP_COMMA() A>::value, // condition std::cout << "ifbranch";, // then std::cout << "elsebranch";); // else return 0; }
There's a few things wrong with this. Firstly you write BOOST_PP_IIF but include <boost/preprocessor/if.hpp> - you probably meant BOOST_PP_IF. But more seriously your "condition" is not a number known at preprocessor-time - i.e. it won't evaluate to a number at pre-processor time, only at compile-time when the boost::is_convertible template magic kicks in. Thus BOOST_PP_IF wouldn't expand as you expect. However, you aren't even seeing an error related to that problem. BOOST_PP_COMMA() is indeed being evaluated before the BOOST_PP_IIF() and thus the compiler is complaining about 4 arguments to the latter macro - compilers do vary in how they expand macros - search the developer's list for Paul Mensonides' essay "How macro expansion works" for more - but you will be safe if your _force_ the COMMA macro to be expanded after the IF one. The following trick occurs over and over in writing preprocessor code: BOOST_PP_IF( X , BOOST_PP_COMMA , BOOST_PP_EMPTY )() Because BOOST_PP_COMMA and BOOST_PP_EMPTY are function-like macros they cannot possibly expand until they are "next to" the (). This can only happen once the BOOST_PP_IF has been evaluated. I.e. the above example will evaluate to a comma if X is non-zero and nothing otherwise.... I'd like to know if there is common name for this trick as I find '"macro name inside the IF, macro arguments outside"-trick' a bit verbose when discussing with colleagues. Pete
There's a few things wrong with this. Firstly you write BOOST_PP_IIF but include <boost/preprocessor/if.hpp> - you probably meant BOOST_PP_IF. Well, <if.hpp> includes <control/if.hpp> which includes <control/iif.hpp>, and I thought I stay at the top level of the boost/preprocessor directory as the content of subdirectories may become subject of change.
But more seriously your "condition" is not a number known at preprocessor-time - i.e. it won't evaluate to a number at pre-processor time, only at compile-time when the boost::is_convertible template magic kicks in. Thus BOOST_PP_IF wouldn't expand as you expect. Hmm, but then, what is the advantage compared to an ordinary #if statement? Actually, I thought that BOOST_PPP_IF is a wrapper for some template "if", e.g. like
template<bool condition, class Then, class Else> struct IF {typedef Then RET;}; template<class Then, class Else> struct IF<false, Then, Else> {typedef Else RET; }; Was this assumption wrong?
However, you aren't even seeing an error related to that problem.
BOOST_PP_COMMA() is indeed being evaluated before the BOOST_PP_IIF() and thus the compiler is complaining about 4 arguments to the latter macro - compilers do vary in how they expand macros - search the developer's list for Paul Mensonides' essay "How macro expansion works" for more - but you will be safe if your _force_ the COMMA macro to be expanded after the IF one. The following trick occurs over and over in writing preprocessor code:
BOOST_PP_IF( X , BOOST_PP_COMMA , BOOST_PP_EMPTY )()
Because BOOST_PP_COMMA and BOOST_PP_EMPTY are function-like macros they cannot possibly expand until they are "next to" the (). This can only happen once the BOOST_PP_IF has been evaluated. I.e. the above example will evaluate to a comma if X is non-zero and nothing otherwise....
Thanks for this explaination, that's really an interesting trick. It's a pity that it doesn't help in this case, but it may be useful otherwise.
I'd like to know if there is common name for this trick as I find '"macro name inside the IF, macro arguments outside"-trick' a bit verbose when discussing with colleagues.
Pete
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Quoting "Warlich, Christof \(Christof\)" <cwarlich@alcatel-lucent.com>:
There's a few things wrong with this. Firstly you write BOOST_PP_IIF but include <boost/preprocessor/if.hpp> - you probably meant BOOST_PP_IF.
Well, <if.hpp> includes <control/if.hpp> which includes <control/iif.hpp>, and I thought I stay at the top level of the boost/preprocessor directory as the content of subdirectories may become subject of change.
Oops sorry I'm misread the include. What you're doing is fine.
But more seriously your "condition" is not a number known at preprocessor-time - i.e. it won't evaluate to a number at pre-processor time, only at compile-time when the boost::is_convertible template magic kicks in. Thus BOOST_PP_IF wouldn't expand as you expect.
Hmm, but then, what is the advantage compared to an ordinary #if statement? Actually, I thought that BOOST_PPP_IF is a wrapper for some template "if", e.g. like
template<bool condition, class Then, class Else> struct IF {typedef Then RET;}; template<class Then, class Else> struct IF<false, Then, Else> {typedef Else RET; };
Was this assumption wrong?
I'm afraid so. BOOST_PP_IF is a preprocessor-time "if". I.e. different code is generated by the preprocessor depending on the value of the first argument. Most compilers have a switch so that you can use do the preprocessing part of compilation if you wish. In your actual case, you'll need to do clas template specicalisation (no macros) to achieve what you want.
participants (1)
-
Filip Konvička -
Peter Bartlett -
Warlich, Christof (Christof)