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

后端 未结 2 950
Happy的楠姐
Happy的楠姐 2021-02-20 11:15

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

相关标签:
2条回答
  • 2021-02-20 11:35

    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.

    0 讨论(0)
  • 2021-02-20 11:38

    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 )

    0 讨论(0)
提交回复
热议问题