[wave] fail to parse variadics macro
Hi, I'm using wave library from boost 1.53.0. Library compiled with default settings, meaning BOOST_WAVE_SUPPORT_VARIADICS_PLACEMARKERS is set to 1 in wave_config.cpp Wave driver is also compiled to support variadics. However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1) And btw, wave driver was called with --variadics option What went wrong here? Thank you, --Alex
I'm using wave library from boost 1.53.0. Library compiled with default settings, meaning BOOST_WAVE_SUPPORT_VARIADICS_PLACEMARKERS is set to 1 in wave_config.cpp
Wave driver is also compiled to support variadics.
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
And btw, wave driver was called with --variadics option
What went wrong here?
Since you have not provided a concise test case I can only guess... From the error message above I can tell, that you forgot the comma in fromnt of the ellipses: #define __builtin_warning(x, y, ...) Which will compile just fine. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Thank you, Hartmut for prompt reply! However, I am not forgetting anything as this definition comes from 'standard' header: http://lxr.free-electrons.com/source/include/linux/compiler.h see line 36: # define __builtin_warning(x, y...) (1) For a test case, trivial TU will suffice: #include <compiler.h> int main() { return 0; } Also, here is a description for variadics from GNU docs: http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html , which corresponds with what I came across in compiler.h So, the question is, would wave process line 36 from compiler.h mentioned above the same way gcc process it? Thank you, --Alex On Monday, March 31, 2014 3:11 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
I'm using wave library from boost 1.53.0. Library compiled with default settings, meaning BOOST_WAVE_SUPPORT_VARIADICS_PLACEMARKERS is set to 1 in wave_config.cpp
Wave driver is also compiled to support variadics.
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
And btw, wave driver was called with --variadics option
What went wrong here?
Since you have not provided a concise test case I can only guess... From the error message above I can tell, that you forgot the comma in fromnt of the ellipses: #define __builtin_warning(x, y, ...) Which will compile just fine. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG On 03/31/2014 12:46 PM, gag maker wrote:
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
Shouldn't that be #define __builtin_warning(x, y, ...) In Christ, Steven Watanabe
On 03/31/2014 03:13 PM, Steven Watanabe wrote:
AMDG
On 03/31/2014 12:46 PM, gag maker wrote:
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
Shouldn't that be
#define __builtin_warning(x, y, ...)
I thought the comma before the ... was optional. Eric
On 4/1/2014 3:51 PM, Eric Niebler wrote:
On 03/31/2014 03:13 PM, Steven Watanabe wrote:
AMDG
On 03/31/2014 12:46 PM, gag maker wrote:
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
Shouldn't that be
#define __builtin_warning(x, y, ...)
I thought the comma before the ... was optional.
My own interpretation of 16.3 paragraph 10 of the 2011 C++ standard (INCITS/ISO/IEC 14882-2011[2012]), given the 3rd #define listed there, is that the comma before the ... is not optional. Is there a further C++ standard or addendum for 2014 that has changed this ?
On 4/1/2014 1:21 PM, Edward Diener wrote:
On 4/1/2014 3:51 PM, Eric Niebler wrote:
On 03/31/2014 03:13 PM, Steven Watanabe wrote:
Shouldn't that be
#define __builtin_warning(x, y, ...)
I thought the comma before the ... was optional.
My own interpretation of 16.3 paragraph 10 of the 2011 C++ standard (INCITS/ISO/IEC 14882-2011[2012]), given the 3rd #define listed there, is that the comma before the ... is not optional. Is there a further C++ standard or addendum for 2014 that has changed this ?
I must've been thinking of C-style varargs, where the comma is optional before the .... Sorry for the noise. Eric
Hi All, I'm asking my question again because I still haven't find any solution to it. When try to build a python application using boost, I'm getting the following error using make. /usr/local/boost_1_55_0/boost/type_traits/is_fundamental.hpp:26:20: fatal error: recursive template instantiation exceeded maximum depth of 128 ::boost::is_arithmetic<T>::value I tried to use ./b2 cxxflags="-ftemplate-depth=256" as mentioned in this topic https://groups.google.com/forum/#!topic/boost-list/KJXwGcugNEs but didn't make any difference. Any idea? I'm really stock! Thanks! Corentin Here is the full output. [ 1%] Building CXX object src/CMakeFiles/pagmo_static.dir/problem/death_penalty.o In file included from /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pagmo-code/src/problem/death_penalty.cpp:29: In file included from /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pagmo-code/src/problem/../types.h:30: In file included from /usr/local/boost_1_55_0/boost/lexical_cast.hpp:165: In file included from /usr/local/boost_1_55_0/boost/type_traits/has_left_shift.hpp:43: In file included from /usr/local/boost_1_55_0/boost/type_traits/detail/has_binary_operator.hpp:15: /usr/local/boost_1_55_0/boost/type_traits/is_fundamental.hpp:26:20: fatal error: recursive template instantiation exceeded maximum depth of 128 ::boost::is_arithmetic<T>::value ^ /usr/local/boost_1_55_0/boost/type_traits/is_fundamental.hpp:38:64: note: in instantiation of template class 'boost::detail::is_fundamental_impl<const double>' requested here BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_fundamental,T,::boost::detail::is_fundamental_impl<T>::value) ^ /usr/local/boost_1_55_0/boost/type_traits/detail/bool_trait_def.hpp:69:30: note: expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_DEF1' BOOST_TT_AUX_BOOL_C_BASE(C) \ ^ /usr/local/boost_1_55_0/boost/type_traits/detail/bool_trait_def.hpp:63:81: note: expanded from macro 'BOOST_TT_AUX_BOOL_C_BASE' # define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant<bool,C> ^ /usr/local/boost_1_55_0/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::is_fundamental<const double>' requested here BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value) ^ /usr/local/boost_1_55_0/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND' # define BOOST_MPL_AUX_VALUE_WKND(C) C ^ /usr/local/boost_1_55_0/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST' # define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr) ^ /usr/local/boost_1_55_0/boost/mpl/eval_if.hpp:37:22: note: in instantiation of template class 'boost::mpl::if_<boost::is_fundamental<const double>, mpl_::int_<1>, boost::mpl::eval_if<boost::is_class<const double>, mpl_::int_<3>, boost::mpl::eval_if<boost::is_array<const double>, mpl_::int_<2>, boost::mpl::eval_if<boost::is_enum<const double>, mpl_::int_<1>, mpl_::int_<0> > > > >' requested here typedef typename if_<C,F1,F2>::type f_; ^ /usr/local/boost_1_55_0/boost/mpl/eval_if.hpp:38:22: note: in instantiation of template class 'boost::mpl::eval_if<boost::is_fundamental<const double>, mpl_::int_<1>, boost::mpl::eval_if<boost::is_class<const double>, mpl_::int_<3>, boost::mpl::eval_if<boost::is_array<const double>, mpl_::int_<2>, boost::mpl::eval_if<boost::is_enum<const double>, mpl_::int_<1>, mpl_::int_<0> > > > >' requested here typedef typename f_::type type; ^ /usr/local/boost_1_55_0/boost/serialization/level.hpp:53:37: note: in instantiation of template class 'boost::mpl::eval_if<boost::is_base_and_derived<boost::serialization::basic_traits, const double>, boost::serialization::implementation_level_impl<const double>::traits_class_level<const double>, boost::mpl::eval_if<boost::is_fundamental<const double>, mpl_::int_<1>, boost::mpl::eval_if<boost::is_class<const double>, mpl_::int_<3>, boost::mpl::eval_if<boost::is_array<const double>, mpl_::int_<2>, boost::mpl::eval_if<boost::is_enum<const double>, mpl_::int_<1>, mpl_::int_<0> > > > > >' requested here BOOST_DEDUCED_TYPENAME mpl::eval_if< ^ /usr/local/boost_1_55_0/boost/serialization/level.hpp:93:12: note: (skipping 119 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) public implementation_level_impl<const T> ^ /usr/local/boost_1_55_0/boost/serialization/export.hpp:66:12: note: in instantiation of member function 'boost::serialization::singleton<boost::archive::detail::pointer_iserializer<boost::archive::text_iarchive, pagmo::problem::death_penalty> >::get_const_instance' requested here >::get_const_instance(); ^ /usr/local/boost_1_55_0/boost/serialization/export.hpp:111:5: note: in instantiation of member function 'boost::archive::detail::export_impl<boost::archive::text_iarchive, pagmo::problem::death_penalty>::enable_load' requested here export_impl<Archive,Serializable>::enable_load( ^ /usr/local/boost_1_55_0/boost/serialization/export.hpp:95:37: note: in instantiation of member function 'boost::archive::detail::ptr_serialization_support<boost::archive::text_iarchive, pagmo::problem::death_penalty>::instantiate' requested here &ptr_serialization_support::instantiate ^ /usr/local/boost_1_55_0/boost/serialization/export.hpp:142:9: note: in instantiation of member function 'boost::archive::detail::extra_detail::guid_initializer<pagmo::problem::death_penalty>::export_guid' requested here export_guid(boost::serialization::is_abstract< T >()); ^ /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pagmo-code/src/problem/death_penalty.cpp:206:1: note: in instantiation of member function 'boost::archive::detail::extra_detail::guid_initializer<pagmo::problem::death_penalty>::export_guid' requested here BOOST_CLASS_EXPORT_IMPLEMENT(pagmo::problem::death_penalty) ^ /usr/local/boost_1_55_0/boost/serialization/export.hpp:167:35: note: expanded from macro 'BOOST_CLASS_EXPORT_IMPLEMENT' >::get_mutable_instance().export_guid(); \ ^ /usr/local/boost_1_55_0/boost/type_traits/is_fundamental.hpp:26:20: note: use -ftemplate-depth=N to increase recursive template instantiation depth ::boost::is_arithmetic<T>::value ^ 1 error generated. make[2]: *** [src/CMakeFiles/pagmo_static.dir/problem/death_penalty.o] Error 1 make[1]: *** [src/CMakeFiles/pagmo_static.dir/all] Error 2 make: *** [all] Error 2
On 4/2/2014 10:24 PM, Corentin Hamel wrote:
Hi All,
I'm asking my question again because I still haven't find any solution to it.
You'll get more traction if: (a) You don't reply to a random message in another thread, which causes threaded mail and news readers (i.e. pretty much all of them) to bury your message where it won't be found, and (b) You put the name of the library that's giving you problems in the subject line. Please take the time to read this: http://www.boost.org/community/policy.html Eric
On 3/31/2014 3:46 PM, gag maker wrote:
Hi,
I'm using wave library from boost 1.53.0. Library compiled with default settings, meaning BOOST_WAVE_SUPPORT_VARIADICS_PLACEMARKERS is set to 1 in wave_config.cpp
Wave driver is also compiled to support variadics.
However, when I try to feed translation unit to wave driver it reports following error: .../compiler.h:32:1: error: ill formed preprocessor directive: #define __builtin_warning(x, y...) (1)
The form '#define __builtin_warning(x, y...)' is not a standard C++ variadic macro but rather a gcc extension to the variadic macro syntax. Since Wave's intention is to follow the C++ standard as closely as possible it is not surprising that it gives an error when processing that non-standard form.
And btw, wave driver was called with --variadics option
What went wrong here?
participants (6)
-
Corentin Hamel -
Edward Diener -
Eric Niebler -
gag maker -
Hartmut Kaiser -
Steven Watanabe