Tanton Gibbs wrote:

Also, I was asked by a coworker if the following would be std C++:

BOOST_PP_LIST_FOR_EACH( DO_IT, BOOST_PP_EMPTY(), ARG_LIST )

I said that it would not because BOOST_PP_EMPTY would be expanded first to nothing, which would be the same as BOOST_PP_LIST_FOR_EACH( DO_IT, , ARG_LIST ) which Paul explicitly said below was non-conformant.

Is this correct?

Well, not exactly, but close. This, for example, is okay: #define EMPTY() #define MACRO(x) x MACRO( ) // undefined MACRO( EMPTY() ) // okay However, this is not: #define MACRO_2(x) MACRO(x) MACRO_2( EMPTY() ) // okay for MACRO_2, undefined for MACRO The reason is relatively simple. Before the argument is inserted into the replacement list of MACRO_2, it is macro expanded. In this case, it expands to nothing, which yields a replacement list like this: MACRO( ) Which is rescanned for macros to expand and consequently introduces undefined behavior. BOOST_PP_LIST_FOR_EACH, as well as virtually every other pp-lib primitive uses other macros, so it is never safe to do this: BOOST_PP_SOME_MACRO( BOOST_PP_EMPTY() ) C99 explicitly allows you to pass nothing as macro argument, but it is still undefined in C++. Regards, Paul Mensonides

Tanton Gibbs wrote:

This makes sense. So, replacement is done after substitution on the RHS, not before macro argument substitution, correct?

In other words, with #define EMPTY() #define MACRO( x ) x

MACRO( EMPTY() ) would have EMPTY() substituted for the formal macro parameter x and the RHS value x. Then, a macros are executed on the RHS changing EMPTY() into nothing (literally).

No. Replacement and rescanning are done on each argument to a function-like macro before they are inserted into the replacement list (unless they are next to the token-pasting operator or the stringizing operator). However, this replacement and rescanning on the parameters happens *after* the arguments are delineated as "actual parameters." So, the replacement list is rescanned *after* the arguments have already been expanded. Take this example: #define X 1, 2 #define A(x) B(x) #define B(a, b) a + b A(X) // 1 + 2 This is perfectly legal and correct. The argument X is delineated as a single parameter to A. This single parameter is expanded and rescanned _prior_ to insertion into the replacement list of A. The expanded result of the parameter is inserted into the replacement list of A, yielding: B(1, 2) Then the replacement list of A is rescanned for more macros to replace--which causes B(1, 2) to be invoked. Note that some preprocessors do not do this expansion order correctly--notably VC++, so consider the above to be illustrative of what is *supposed* to happen. Make sense? Regards, Paul Mensonides

Yes, I think he just has a problem with using a placeholder value, he wants to show, at the call site, that the value is not used. ----- Original Message ----- From: "Paul Mensonides" To: Sent: Tuesday, May 06, 2003 6:30 PM Subject: [Boost-Users] Re: RE: PP Library...

Tanton Gibbs wrote:

...

Also, I was asked by a coworker if the following would be std C++:

[...]

BTW, are looking for a way to pass data as a macro argument sometimes and other times pass nothing?

Paul Mensonides

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/