10

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!

moka
  • 4,353
  • 2
  • 37
  • 63
  • 4
    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. – ildjarn Nov 17 '11 at 20:29
  • 1
    hmm yeah that is most likely it.- Seems weird though since all boost macros start with BOOST_ and are thus rather unique. ty! – moka Nov 17 '11 at 20:43
  • 5
    I don't mean to say that `Cocoa.h` is defining a macro beginning with `BOOST_`; I mean to say that `Cocoa.h` is defining a macro named `Lhs` or `Rhs` or `has_operator` or somesuch other terrible macro name, and that it's conflicting with the proper identifiers in use in the Boost code. – ildjarn Nov 17 '11 at 20:46
  • 1
    thanks for the clarification.- Hope that will be fixed in the next release because this is somewhat of an annoyance. – moka Nov 17 '11 at 23:42
  • The header causes a similar bug in combination with Qt. So you might want to look for something related in the bug tracker. – pmr Dec 05 '11 at 23:40

2 Answers2

16

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 )

shadowspawn
  • 3,039
  • 22
  • 26
  • Using boost 1.55 on OS X 10.9.2 and this answer is still relevant and correct. It seems that this has been fixed in type_traits as of 3 weeks ago. See the bug report listed above for more info. – vmrob May 13 '14 at 02:57
3

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.

ildjarn
  • 62,044
  • 9
  • 127
  • 211