id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 6219,Apple macros break compile of has_binary_operator,John Gee ,Vladimir Prus,"Short version: the Apple defined macro for check() breaks the compile of some files in Boost 1.48. Long version I upgraded from Boost 1.44 to 1.48 and my compile broke. A little digging determined it is a conflict with the check() macro defined in AssertMacros.h which currently makes its way into many compiles. This problem has come up before, see [https://svn.boost.org/trac/boost/ticket/2115]. I am compiling on Mac OS X Lion v10.7.2 with Apple LLVM compiler 3.0. This code is enough to show the problem: #include #include ""boost/type_traits.hpp"" or more directly #include #include ""boost/type_traits.hpp"" The first errors happen in this code in has_binary_operator.hpp where check is used. {{{ template < typename Lhs, typename Rhs > struct operator_exists { static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists static ::boost::type_traits::no_type check(no_operator); // this version is used otherwise BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make() BOOST_TT_TRAIT_OP make()),make())))==sizeof(::boost::type_traits::yes_type))); }; }}} Of some interest, Apple is aware of the problems being caused by the too-ordinary macro names and this text appears in the AssertMacros.h header: {{{ * Prior to Mac OS X 10.6 the macro names used in this file conflicted with some * user code, including libraries in boost and the proposed C++ standards efforts, * and there was no way for a client of this header to resolve this conflict. Because * of this, most of the macros have been changed so that they are prefixed with * __ and contain at least one capital letter, which should alleviate the current * and future conflicts. However, to allow current sources to continue to compile, * compatibility macros are defined at the end with the old names. A tops script * at the end of this file will convert all of the old macro names used in a directory * to the new names. Clients are recommended to migrate over to these new macros as * they update their sources because a future release of Mac OS X will remove the * old macro definitions ( without the double-underscore prefix ). Clients who * want to compile without the old macro definitions can define the macro * __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is * included. }}} (So there is a work-around in client code.) ",Bugs,closed,To Be Determined,type_traits,Boost 1.48.0,Problem,fixed,,j.gee@…