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 <j.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 <Carbon/Carbon.h>
#include ""boost/type_traits.hpp""

or more directly
#include <AssertMacros.h>
#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<Lhs>() BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==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@…