我正在尝试将一个简单的 Swift 应用程序 ( here ) 从使用 Swift 数据模型转换为 C++ 模型。我找到了一篇文章 ( here )，内容是关于使用 Obj-C++ 包装 C++ 代码以便将 C++ 模型暴露给 Swift。
我已经完成转换并且没有编译器警告/错误，直到我将我的 Obj-C++“包装器” header 放入 <xx>-Bridging-Header.h .在桥接头内，我有一个 #include到我的 Obj-C++“包装器”头文件。该 Obj-C++ 包装类当然直接链接到我的 C++ 类 header 。尝试编译时，我从 Swift 收到一个错误 <unordered_map>无法找到。
这是有道理的，因为我不希望 Swift 了解有关 C++ 或其任何头文件的任何信息。我认为桥接 header 的意义在于让 Obj-C++ 编译器能够启动并适本地编译代码。
在build设置中，我确保在 LLVM 6.0 C++ 编译器设置下使用了 C++11 编译器标志。但是，似乎没有使用除 Swift 之外的任何编译器。并且，删除 <unordered_map>来自 C++ header 的依赖项，它无法找到 <vector> ，所以我相信这与 C++ 11 无关。
如果有人能在这里指出我正确的方向，将不胜感激!
最佳答案
在线搜索我能找到的唯一例子正是我正在尝试做的——但没有实际的类(class)。每个示例本质上都是一个 C 头文件和实现，但具有 STL 支持。在网上找不到与此问题相关的信息后，我开始了没有头绪的人往往会做的事情——盲目修补。
我发现的是关于 C++ 模型的 Obj-C++“包装器”文件。最初，我以纯 C++ 方式处理我的 #include:在 Obj-C++ 包装器 header 中，我包含了我的 C++ 模型 header 。
我一直遵循这一点，并且在 .mm 实现文件中也有匹配的 #include(正如我在 C++ 类(class)中所学的那样)。
类似于一个国家从另一个国家解散并改变他们所有的习俗以向母国示好，显然 NeXT 用 C++ 做了同样的事情。头文件(除了它们的 Foundation)希望仅属于实现文件。
按照此更改我的代码后，其他编译器警告很容易解决，项目编译正常。
在使用这个解决方案之前，我已经放弃了必须从 C++ 文件中创建一个动态库并将它们以这种方式合并到项目中的想法。这仍然是一个可行的替代方案，并且在某些情况下可能是首选(尽管确实存在少量开销)。
关于来自 Bridging-Header Obj-C++ 的 C++ header 问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27892868/