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