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?
我正在编写一个图形应用程序,使用Objective-C作为前端,使用C ++进行图形处理和网络通信。我在Apple的网站上阅读,寻找一种方法将.dylib或.so与我的C ++代码链接到我的Xcode项目,但似乎没有任何效果。我能够让项目引用它并链接它,但当我试图从.dylib调用函数时,它说它不知道我想要做什么。有谁知道这里发生了什么?
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?
我知道Objective-C有我需要的所有库来做图形和网络,但我只是觉得这样做。我有一段时间没有做太多的C ++,我想学习更多的Objective-C,那么有什么比一起使用更好的方法呢?
Thanks, Robbie
2 个解决方案
#1
13
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.
你将以所谓的“名称修改”的形式遇到一个障碍。 C ++以与Obj-C不兼容的方式存储函数名称。
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
Objective-C没有像C ++一样实现类,所以它不会喜欢它。
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! :)
解决这个问题的一种方法是实现一组调用C ++函数的简单C函数。保持C函数的数量尽可能低是一个很好的挑战!你最终会得到一个漂亮的紧凑界面! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
要在C ++文件中声明这些函数,您需要将它们标记为C:
extern "C" int function_name(char *blob,int number, double foo) {...}
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.
使用您可以与目标C代码共享的所有这些函数的原型构建头文件。
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).
您将无法以相同的方式传递类(因为您的ObjC代码不能使用它们),但您将能够传递指针(尽管您可能不得不对这些类型稍微撒谎)。
#2
14
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.
我工作的大多数项目都有一个ObjC前端和C ++后端。如果你只处理函数,那么Dave Gamble的名称修复是正确的,但是如果你正在处理更复杂的情况,你需要处理ObjC和C ++对象,你最好的办法是包装C ++对象在ObjC对象中。使用不透明引用(这是一种非常奇特的方式表示void *),您实际上可以在ObjC中处理C ++对象,反之亦然。我有一些可能有用的示例代码。
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 ++而不是使用Core Image和相关框架时受到严重影响。 Core Image和其他图形框架针对Mac进行了高度优化,使用手动C ++(甚至是非常适合Mac的编写得很好的C ++)也不太可能做得更好。当你转向10.6和盛大的*调度时,性能差异将更加显着,因为你将失去你将免费获得的所有并行化进展。这与ObjC无关; Core Image是C.你可以用C ++来调用它。我建议不要使用任何语言在Mac上进行自定义图形处理,除非您需要便携性或者您具备击败Core Image所需的专业知识。
#1
13
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.
你将以所谓的“名称修改”的形式遇到一个障碍。 C ++以与Obj-C不兼容的方式存储函数名称。
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
Objective-C没有像C ++一样实现类,所以它不会喜欢它。
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! :)
解决这个问题的一种方法是实现一组调用C ++函数的简单C函数。保持C函数的数量尽可能低是一个很好的挑战!你最终会得到一个漂亮的紧凑界面! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
要在C ++文件中声明这些函数,您需要将它们标记为C:
extern "C" int function_name(char *blob,int number, double foo) {...}
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.
使用您可以与目标C代码共享的所有这些函数的原型构建头文件。
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).
您将无法以相同的方式传递类(因为您的ObjC代码不能使用它们),但您将能够传递指针(尽管您可能不得不对这些类型稍微撒谎)。
#2
14
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.
我工作的大多数项目都有一个ObjC前端和C ++后端。如果你只处理函数,那么Dave Gamble的名称修复是正确的,但是如果你正在处理更复杂的情况,你需要处理ObjC和C ++对象,你最好的办法是包装C ++对象在ObjC对象中。使用不透明引用(这是一种非常奇特的方式表示void *),您实际上可以在ObjC中处理C ++对象,反之亦然。我有一些可能有用的示例代码。
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 ++而不是使用Core Image和相关框架时受到严重影响。 Core Image和其他图形框架针对Mac进行了高度优化,使用手动C ++(甚至是非常适合Mac的编写得很好的C ++)也不太可能做得更好。当你转向10.6和盛大的*调度时,性能差异将更加显着,因为你将失去你将免费获得的所有并行化进展。这与ObjC无关; Core Image是C.你可以用C ++来调用它。我建议不要使用任何语言在Mac上进行自定义图形处理,除非您需要便携性或者您具备击败Core Image所需的专业知识。