链接和使用 C++ 带有 Objective-C 应用程序的库
我正在编写一个图形应用程序，使用 Objective-C 作为前端，使用 C++ 进行图形处理和网络通信。 我在 Apple 网站上四处阅读，寻找一种将包含 C++ 代码的 .dylib 或 .so 链接到我的 Xcode 项目的方法，但似乎没有任何效果。 我能够让项目引用它并链接到它，但是当我尝试从该 .dylib 调用函数时，它说它不知道我要做什么。 有谁知道这是怎么回事？
我知道 Objective-C 拥有我进行图形和网络处理所需的所有库，但我只是想这样做。 我已经有一段时间没有接触太多 C++ 了，我想学习更多 Objective-C，那么还有什么比一起使用它们更好的方法呢？
谢谢， 罗比
I'm writing a graphical application using Objective-C for the front end and C++ for the graphics processing and network communication. I read around on Apple's site looking for a way to link either a .dylib or .so with my C++ code in it to my Xcode project, but nothing seemed to work. I was able to get the project to reference it and link against it, but when I tried to call functions from that .dylib, it was saying that it didn't know what I was trying to do. Does anyone know what is going on here?
I know that Objective-C has all the libraries I would need to do graphics and networking, but I just feel like doing it like this. I haven't done much C++ in a while and I want to learn more Objective-C, so what better way than to use them together?
Thanks,
Robbie
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我从事的大多数项目都有 ObjC 前端和 C++ 后端。 如果您专门处理函数，那么 Dave Gamble 的 name mangle fix 是正确的，但如果您正在处理更复杂的情况，需要同时处理 ObjC 和 C++ 对象，那么最好的选择是包装 C++ 对象在 ObjC 对象中。 使用不透明引用（这是
void*的一种非常奇特的表达方式），您实际上可以在 ObjC 中传递 C++ 对象，反之亦然。 我有一些示例代码可能会有所帮助。也就是说，对于图形来说，使用自定义 C++ 而不是使用 Core Image 和相关框架可能会严重影响性能。 Core Image 和其他图形框架针对 Mac 进行了高度优化，并且您不太可能使用手写的 C++（甚至不是专门针对 Mac 编写的非常好的 C++）做得更好。 当您迁移到 10.6 和中央调度时，性能差异将更加显着，因为您将失去所有可以免费获得的并行化进步。 这与 ObjC 无关； Core Image 是 C 语言。您可以从 C++ 中调用它。 我只是建议不要在 Mac 上以任何语言进行自定义图形处理，除非您需要可移植性或者您拥有击败 Core Image 所需的专业知识。
Most of the projects I work on have an ObjC frontend and C++ backend. If you're dealing exclusively with functions, then Dave Gamble's name mangle fix is correct, but if you're dealing with more complex situations, where you need to deal with both ObjC and C++ objects, your best bet is to wrap the C++ objects in ObjC objects. Using opaque references (which is a very fancy way of saying
void*), you can actually hand around C++ objects in ObjC and vice versa. I have some sample code that may be helpful.That said, for graphics you're probably going to take a serious performance hit doing custom C++ rather than using Core Image and the related frameworks. Core Image and the other graphics frameworks are highly optimized for the Mac, and you're very unlikely to do better with hand-rolled C++ (or even very well-written C++ that isn't specifically for the Mac). As you move to 10.6 and grand central dispatch, the performance difference is going to be even more notable because you'll lose all the parallelization advances that you would get for free otherwise. This has nothing to do with ObjC; Core Image is C. You can call it from C++ all you like. I just recommend against custom graphics processing on Mac in any language unless you need portability or you have the expertise necessary to beat Core Image.
您将遇到一个障碍，即所谓的“名称修改”。 C++ 存储函数名称的方式与 Obj-C 不兼容。
Objective-C 实现类的方式与 C++ 不同，所以它不会喜欢它。
解决此问题的一种方法是实现一组调用 C++ 函数的简单 C 函数。 保持 C 函数的数量尽可能少将是一个很好的挑战！ 你最终会得到一个漂亮紧凑的界面！ :)
要在 C++ 文件中声明这些函数，您需要将它们标记为 C：
这将禁用标准名称修改。
使用所有这些函数的原型构建一个头文件，您可以与目标 C 代码共享。
您将无法以相同的方式传递类（因为您的 ObjC 代码无法使用它们），但您将能够传递指针（尽管您可能需要对类型撒一些谎）。
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).