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_p
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.
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 )