[preprocessor]BOOST_PP_CHECK_2 with wrong number args
boost/preprocessor/detail/check.hpp in boost version 1.47.0 contains: # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() && ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_DMC() # define BOOST_PP_CHECK_D(x, type) BOOST_PP_CHECK_1(BOOST_PP_CAT(BOOST_PP_CHECK_RESULT_, type x)) # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk) # define BOOST_PP_CHECK_2(res, _) res # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() The above shows BOOST_PP_CHECK_2 is called with 1 argument on rhs of BOOST_CHECK_1; yet, the arity is 2, as shown on the next line. This results in the errors reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 when that line is changed to: # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_) the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2. Is this a BOOST_PP bug? If not; how can the errors reported in: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 be avoided? TIA. -regards, Larry
On 8/24/2011 2:15 PM, Larry Evans wrote:
boost/preprocessor/detail/check.hpp in boost version 1.47.0 contains:
# if ~BOOST_PP_CONFIG_FLAGS()& BOOST_PP_CONFIG_MSVC()&& ~BOOST_PP_CONFIG_FLAGS()& BOOST_PP_CONFIG_DMC() # define BOOST_PP_CHECK_D(x, type) BOOST_PP_CHECK_1(BOOST_PP_CAT(BOOST_PP_CHECK_RESULT_, type x)) # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk) # define BOOST_PP_CHECK_2(res, _) res # elif BOOST_PP_CONFIG_FLAGS()& BOOST_PP_CONFIG_MSVC()
The above shows BOOST_PP_CHECK_2 is called with 1 argument on rhs of BOOST_CHECK_1; yet, the arity is 2, as shown on the next line.
This results in the errors reported here:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
when that line is changed to:
# define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_)
the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2.
Is this a BOOST_PP bug? If not; how can the errors reported in:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
be avoided?
I believe it is allowable because of placeholder expressions, but this may have been because of C99, whereas a preprocessor that does not support C99 may not work. BTW, nothing has changed with BOOST_PP_CHECK with Boost 1.47, as the code has appeared the way it is for a long time. What compiler are you using ? Is there a C99 or a C++0x mode you can turn on in the command line somehow ?
On 08/24/11 16:34, Edward Diener wrote: [snip]
This results in the errors reported here:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
when that line is changed to:
# define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_)
the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2.
Is this a BOOST_PP bug? If not; how can the errors reported in:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
be avoided?
I believe it is allowable because of placeholder expressions, but this may have been because of C99, whereas a preprocessor that does not support C99 may not work.
BTW, nothing has changed with BOOST_PP_CHECK with Boost 1.47, as the code has appeared the way it is for a long time.
What compiler are you using ? Is there a C99 or a C++0x mode you can turn on in the command line somehow ?
Here's the compile command and part of output: /home/evansl/download/gcc/4.6.0-release/install/bin/g++ -c -Wall -ftemplate-depth-300 -O0 -fpermissive -I. -I/home/evansl/prog_dev/boost-svn/ro/boost_1_47_0 curryable.cpp In file included from /home/evansl/prog_dev/boost-svn/ro/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward2.hpp:50:0, from ./curryable.hpp:157, from /home/evansl/prog_dev/boost-svn/ro/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:47, from curryable.hpp:113, from curryable.cpp:1: ./curryable.hpp:117:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ./curryable.hpp:117:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given I don't see anything on the above command line that indicates a c99 or c++0x mode, except maybe the -fpermissive. Thanks for the help. -regards, Larry
On 8/24/2011 5:57 PM, Larry Evans wrote:
On 08/24/11 16:34, Edward Diener wrote: [snip]
This results in the errors reported here:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
when that line is changed to:
# define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_)
the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2.
Is this a BOOST_PP bug? If not; how can the errors reported in:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
be avoided?
I believe it is allowable because of placeholder expressions, but this may have been because of C99, whereas a preprocessor that does not support C99 may not work.
BTW, nothing has changed with BOOST_PP_CHECK with Boost 1.47, as the code has appeared the way it is for a long time.
What compiler are you using ? Is there a C99 or a C++0x mode you can turn on in the command line somehow ?
Here's the compile command and part of output:
/home/evansl/download/gcc/4.6.0-release/install/bin/g++ -c -Wall -ftemplate-depth-300 -O0 -fpermissive -I. -I/home/evansl/prog_dev/boost-svn/ro/boost_1_47_0 curryable.cpp In file included from /home/evansl/prog_dev/boost-svn/ro/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward2.hpp:50:0, from ./curryable.hpp:157, from /home/evansl/prog_dev/boost-svn/ro/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:47, from curryable.hpp:113, from curryable.cpp:1: ./curryable.hpp:117:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given ./curryable.hpp:117:1: error: macro "BOOST_PP_CHECK_2" requires 2 arguments, but only 1 given
I don't see anything on the above command line that indicates a c99 or c++0x mode, except maybe the -fpermissive.
Thanks for the help.
I have Eric Niebler's curryable.h. Is that your header file renamed to curryable.hpp ? What doe curryable.cpp look like ? If I can know the exact curryable.hpp and curryable.cpp you are using I can try it out with gcc-4.6.0 using MingW under Windows and see what my results are.
On 08/24/11 17:20, Edward Diener wrote: [snip]
I have Eric Niebler's curryable.h. Is that your header file renamed to curryable.hpp ? What doe curryable.cpp look like ? Just #include's curryable.hpp.
If I can know the exact curryable.hpp and curryable.cpp you are using I can try it out with gcc-4.6.0 using MingW under Windows and see what my results are. They're attached. Thanks.
-Larry
On 8/24/2011 6:33 PM, Larry Evans wrote:
On 08/24/11 17:20, Edward Diener wrote: [snip]
I have Eric Niebler's curryable.h. Is that your header file renamed to curryable.hpp ? What doe curryable.cpp look like ? Just #include's curryable.hpp.
If I can know the exact curryable.hpp and curryable.cpp you are using I can try it out with gcc-4.6.0 using MingW under Windows and see what my results are. They're attached.
I see the same error that you see with gcc-4.6.0 against Boost 1.47. Worse still I see a different error using gcc-4.6.0 against the Boost trunk. I know when I worked with Paul Mensonides in updating Boost PP on the Boost trunk to add variadic macro support, Paul said he also made changes to some of the iterate code, but evidently one of those changes has broken something preprocessor use in Eric's code. I will contact Paul and see if he knows how his changed has affected iteration and also why BOOST_PP_CHECK is coded the way it is ( and has been for a long time ). Then I will get back to you on this thread. Eddie
On 8/24/2011 6:33 PM, Larry Evans wrote:
On 08/24/11 17:20, Edward Diener wrote: [snip]
I have Eric Niebler's curryable.h. Is that your header file renamed to curryable.hpp ? What doe curryable.cpp look like ? Just #include's curryable.hpp.
If I can know the exact curryable.hpp and curryable.cpp you are using I can try it out with gcc-4.6.0 using MingW under Windows and see what my results are. They're attached. Thanks.
Paul Mensonides explains why this error is occuring in the "painless currying" thread. The main gist for solving the compiler issue with gcc is to change: #elif BOOST_PP_ITERATION_FLAGS() == 1 to #else #if BOOST_PP_ITERATION_FLAGS() == 1 and to use the Boost PP code in the Boost trunk.
On 09/01/11 15:58, Edward Diener wrote:
On 8/24/2011 6:33 PM, Larry Evans wrote:
On 08/24/11 17:20, Edward Diener wrote: [snip]
I have Eric Niebler's curryable.h. Is that your header file renamed to curryable.hpp ? What doe curryable.cpp look like ? Just #include's curryable.hpp.
If I can know the exact curryable.hpp and curryable.cpp you are using I can try it out with gcc-4.6.0 using MingW under Windows and see what my results are. They're attached. Thanks.
Paul Mensonides explains why this error is occuring in the "painless currying" thread. The main gist for solving the compiler issue with gcc is to change:
#elif BOOST_PP_ITERATION_FLAGS() == 1
to
#else #if BOOST_PP_ITERATION_FLAGS() == 1
and to use the Boost PP code in the Boost trunk. Thanks Edward and Paul. I made the suggested change and now it's compiling.
-regards, Larry
On 08/24/11 13:15, Larry Evans wrote: [snip]
Is this a BOOST_PP bug? If not; how can the errors reported in:
http://article.gmane.org/gmane.comp.lib.boost.devel/222795
be avoided?
[snip] In case it's relevant: make environment /home/evansl/download/gcc/4.6.0-release/install/bin/g++ -c -Wall -ftemplate-depth-300 -O0 -fpermissive -v Using built-in specs. COLLECT_GCC=/home/evansl/download/gcc/4.6.0-release/install/bin/g++ COLLECT_LTO_WRAPPER=/home/evansl/download/gcc/4.6.0-release/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/evansl/download/gcc/4.6.0-release/build/../src/configure --prefix=/home/evansl/download/gcc/4.6.0-release/build/../install --enable-languages=c++ --enable-checking=assert,misc,tree,gc,rtl,runtime Thread model: posix gcc version 4.6.0 (GCC) uname -a Linux evansl-desktop 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 x86_64 GNU/Linux
participants (2)
-
Edward Diener -
Larry Evans