I was trying to trace the output of a macro within a preprocessor directive in a file using the Wave trace facility. The directive is: #elif BOOST_PP_ITERATION_FLAGS() == 1 so I specified: #pragma wave trace(enable) #elif BOOST_PP_ITERATION_FLAGS() == 1 #pragma wave trace(disable) But wave's trace showed me an empty file where the macro output ( -tsomefile ) should have been. Is there a way to capture the output of the BOOST_PP_ITERATION_FLAGS() macro at the point where the #elif is occuring using Wave's trace facility ?
On Mon, 29 Aug 2011 15:27:43 -0400, Edward Diener wrote:
I was trying to trace the output of a macro within a preprocessor directive in a file using the Wave trace facility. The directive is:
#elif BOOST_PP_ITERATION_FLAGS() == 1
so I specified:
#pragma wave trace(enable) #elif BOOST_PP_ITERATION_FLAGS() == 1 #pragma wave trace(disable)
But wave's trace showed me an empty file where the macro output ( -tsomefile ) should have been.
Is there a way to capture the output of the BOOST_PP_ITERATION_FLAGS() macro at the point where the #elif is occuring using Wave's trace facility ?
If this is from the curryable.hpp file, gcc does attempt to parse all of the #if/#elif directives for the level it is currently on. E.g. #if !BOOST_PP_IS_ITERATING // okay, will "decay" to 0 if not defined // ... #elif BOOST_PP_ITERATION_FLAGS() == 2 // will cause error // when not iterating, iteration flags is not defined // so this will result in 0() == 2 which is a syntax error // ... #endif The "problem" is that gcc requires a well-formed expression even if the first branch of #if is taken. The fix is to do this: #if !BOOST_PP_IS_ITERATING // ... #else #if BOOST_PP_ITERATION_FLAGS() == 2 // ... #endif #endif
On 8/30/2011 5:12 AM, Paul Mensonides wrote:
On Mon, 29 Aug 2011 15:27:43 -0400, Edward Diener wrote:
I was trying to trace the output of a macro within a preprocessor directive in a file using the Wave trace facility. The directive is:
#elif BOOST_PP_ITERATION_FLAGS() == 1
so I specified:
#pragma wave trace(enable) #elif BOOST_PP_ITERATION_FLAGS() == 1 #pragma wave trace(disable)
But wave's trace showed me an empty file where the macro output ( -tsomefile ) should have been.
Is there a way to capture the output of the BOOST_PP_ITERATION_FLAGS() macro at the point where the #elif is occuring using Wave's trace facility ?
If this is from the curryable.hpp file, gcc does attempt to parse all of the #if/#elif directives for the level it is currently on. E.g.
#if !BOOST_PP_IS_ITERATING // okay, will "decay" to 0 if not defined
// ...
#elif BOOST_PP_ITERATION_FLAGS() == 2 // will cause error // when not iterating, iteration flags is not defined // so this will result in 0() == 2 which is a syntax error
// ...
#endif
The "problem" is that gcc requires a well-formed expression even if the first branch of #if is taken. The fix is to do this:
#if !BOOST_PP_IS_ITERATING
// ...
#else
#if BOOST_PP_ITERATION_FLAGS() == 2
// ...
#endif
#endif
It is indeed curryable.hpp. I made the changes you suggest above to curryable.hpp. A normal compile using gcc now works without errors against Boost PP on the trunk ( your iteration changes work ) , but still gives the same errors as before against Boost 1.47: In file included from C:\Utilities\Boost\boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward2.hpp:50:0, from ..\..\../curryable.hpp:158, from C:\Utilities\Boost\boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:47, from ..\..\../curryable.hpp:113, from curryable.cpp:1: ..\..\../curryable.hpp:118:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ..\..\../curryable.hpp:118:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ..\..\../curryable.hpp:118:1: error: pasting ")" and "BOOST_PP_CAT" does not give a valid preprocessing token ..\..\../curryable.hpp:177:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ..\..\../curryable.hpp:177:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ..\..\../curryable.hpp:177:1: error: pasting ")" and "BOOST_PP_CAT" does not give a valid preprocessing token
participants (2)
-
Edward Diener -
Paul Mensonides