c++: Boost 1.48 type traits and Cocoa inclusion weirdness

Question

I just updated boost to version 1.48.0 on a project i am developing on OSX Lion that also includes the Cocoa headers. After doing so I got a load of errors all pointing to has_prefix_operator.hpp and has_binary_operator.hpp which all point to lines like i.e.:

   BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==sizeof(::boost::type_traits::yes_type)));

../../boost_1_48_0/boost/type_traits/detail/has_binary_operator.hpp:157:4: error: expected expression [1]

After trying around, since I could not really read any sense into these errors, I noticed that if I switch the inclusion order from:

#import <Cocoa/Cocoa.h>
#include <boost/type_traits.hpp>

to

#include <boost/type_traits.hpp>
#import <Cocoa/Cocoa.h>

things magically work. I am very confused about that since it worked just fine with the previous boost release and I have no clue why this is happening. Any ideas about what might be going on?

Thanks!

Answer 1

I had essentially the same problem, and with the clue from ildjam, I found the cause and a work-around.

The (terrible) macro name is check, defined in AssertMacros.h. According to the comments in that file, in the future Apple will remove the old names. For now Apple have added a work-around to suppress the old names which is to define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before AssertMacros.h is processed. e.g.

#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
#import <Cocoa/Cocoa.h>

If you use a prefix file, then you could put the definition there. Alternatively, a direct work-around is to undef check before including type_traits.hpp.

#ifdef check
#undef check
#endif
#include "boost/type_traits.hpp"

(Details submitted to Boost Trac too: https://svn.boost.org/trac/boost/ticket/6219 )

Answer 2

^{Reposting from comments since this apparently is the answer...}

It seems Cocoa.h is directly or indirectly defining a macro with the same name as one of the identifiers used in the Boost code. I.e., Cocoa.h is defining a macro named Lhs or Rhs or has_operator or some other equally terrible macro name, and it's conflicting with the proper identifiers in use in the Boost code.

If you'd like to contribute to getting this fixed in a future version of Boost, please narrow down the offending macro name(s) and submit a bug report on Boost Trac.