Objective-C ++导入C ++类失败，cassert找不到
所以我想在我的cocos2d + box2d项目中公开一个Box2D（C ++）指向其他Objective-C ++类的指针。 我在我的接口中声明了一个方法“getWorld”，它引用C ++类b2World并导入Box2D.h。 我的项目中的所有文件都是.mm扩展名，并且出现以下编译错误：
In file included from DebugDrawLayer.mm:2: In file included from World.h:10: In file included from external/Box2d/Box2D/Box2D.h:34: external/Box2d/Box2D/Common/b2Settings.h:22:10: fatal error: 'cassert' file not found #include <cassert> 我猜Box2D.h不知何故编译为C而不是C ++，但我不明白这是怎么发生的。 根据日志，包含链清楚地从一个.mm文件开始。
更新：
日志说World.mm（早先编译），它清楚地编译为objective-c ++
CompileC Objects-normal/i386/World.o World.mm normal i386 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler
但是对于DebugDrawLayer.mm，它表示objective-c
CompileC Objects-normal/i386/DebugDrawLayer.o DebugDrawLayer.mm normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
这两个文件都被设置为默认 – Objective-C ++源代码。 是什么赋予了..？
这似乎是Xcode4中的一个主要错误，与编译器设置无关 – 只是Xcode内部。
更新：
我最终find了根本原因。 是的，这是Xcode / LLVM中的一个错误。 它以错误的顺序编译文件，然后覆盖自己的设置，并自行中断。 苹果的技术支持太不能理解这个问题，所以我怀疑他们很快就会修复这个bug。
（注意：跳过这个部分，看下面的原始答案，它给出了一个BRUTE FORCE，但是很快做到了）
会发生什么……如果编译器在处理 C类时 “看到”一个C ++头文件…那么它会把这个头文件（内部）标记为“C”（即使这在字面上是不可能的）。
后来，当它回到头部，试图用C ++进行编译时，发现它已经告诉自己头部是“C”（因为它非常愚蠢），并且迅速崩溃。
正确的解决scheme（这需要大量的时间和精力）是通过项目中的每个C文件，并检查（手动，因为Xcode吸）每个引用每个头文件 – 每一个，每个头文件import…等
（这可能需要几个小时）
…直到find导致C文件“看到”C ++头的导入链。
所有这些都应该是自动的（但不是）。 而根本问题不应该发生（如果Xcode被正确书写）。
我尝试了网上其他地方列出的所有东西，大部分解决scheme是“不断删除/添加文件，最终Xcode会自行修复”。
我没有运气。 唯一的工作是：
- 去build立您的项目设置
- find“编译源代码”设置
- 将其设置为“Objective-C ++”
- 重build
实际的名称/值是：“GCC_INPUT_FILETYPE = sourcecode.cpp.objcpp” – 所以我的猜测是，这避开了Xcode的（破碎！）内部逻辑。
我有同样的错误，我只是重命名我的类（从我称之为box2d类）从className.m到className.mm现在它的作品。
从项目中删除DebugDrawLayer，然后重新添加它解决了这个问题。 也许在构build阶段设置文件中有一些奇怪的编译器设置，从来没有检查过这些。
我在Cocos2D / Box2D项目中遇到了这个问题，直到我将我的项目中的所有.m文件（当然不包括Cocos2D中的.m文件）重新.mm为.mm ， .mm将它们编译为Objective-C ++。
我猜@亚当的解决scheme也适用，但我更喜欢离开编译设置为“根据文件types”，感觉更干净。
其实正确的解决scheme是把你的代码放到：
#if __cplusplus // … your code … #endif // __cplusplus
在Prefix.pch有#import "Box2D.h"时，我遇到了这个问题。 我将#import "Box2D.h"改为在每个使用它的文件中。