Boost logo

Boost Users :

From: Warlich, Christof \(Christof\) (cwarlich_at_[hidden])
Date: 2008-03-13 12:48:57


> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net