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
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.
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:
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.
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).
Related
I'm building a cross-platform mobile application and I was suggested to use OF environment and compile my application using Xcode. I'm a Mac user and I started programming few time ago (so I'm really a beginner).
I need some class to get information about position and rotation so I was thinking to have a look at some SDK such as MoSync or CMDeviceMotion in order to understand which one is the most suitable to my purpose.
I also noted here:
https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMDeviceMotion_Class/index.html#//apple_ref/doc/c_ref/CMDeviceMotion
that CMDeviceMotion is written for Obj-C and Swift.
So I have two question:
is it possible add to the main project libraries that are not part of OF?
should I use only C/C++ class?
Thanks.
I'm not sure if stackoverflow is the right place to ask a q like this, since any answer is very much prone to subjectivity.
I don't think there's a lot of valid reasons to even try to connect "MoSync" with OF, since they are both in a way "platforms" for developing apps, supporting different languages (javascript on the first and c++ on the latter). It is possible to mix objective-c (and swift) code with c++, so you can combine CMDeviceMotion with OF.
However to answer your question: It seems that if you want to have device information you don't need to go out of the scope of openFrameworks. Take a look at the "ofxIOSCoreLocation"class of OpenFrameworks/ofxIOS. It provides means for altitude, location, direction and so forth.
It is very possible to cross Objective-C and C++ with what is called Objective-C++ (by standard .mm instead of cpp), in openFrameworks.
Limitations and features: https://en.wikipedia.org/wiki/Objective-C#Objective-C.2B.2B
You can then from the Objective-C++ class (lets say for example ofApp.h), call Objective C delegates and functions directly.
You can not embed swift like this, however you there are some methods of using objective-c middle man class.
I've got a DSP audio aglo in C# that I'd like to incorporate into iOS. A friend suggested that I convert to C++ instead of Objective-C, as it would be platform agnostic. Is this a good practice, any pitfalls to be aware of? My instinct is to keep it native with Obj-C. How would I access C++ functions within iOS?
Thank you
You can freely mix C++ with Objective-C, it's known as "Objective-C++". To let the compiler know that is your intent, you need to rename you .m file as .mm.
Mixing code like that is not necessarily a good idea, and fairly pointless if you aim is portability. Better is to keep you C++ in separate .cpp files, and create a bare-bones wrapper class (obj-c++) to pass data between your objective-C and C++ objects (effectively the wrapper is mediating obj-C methods and C++ functions to send and return data).
I have recently posted a couple of simple image processing examples of this on github - openCVSquares and openCVStitch. It's worth you taking a look, just to see how the C++ code is separated out from obj-C.
The openCV libraries have a C++ interface, so using C++ in the project is unavoidable. It would be possible to mash all of the code into .mm files, but that's an easy way to make a mess.
As regards portability, you get this by separating your UI code from your data-manipulation code. You should be doing this anyway for MVC, so it will be little additional work to write your model in C++ as per these examples. The model is portable, the UI is - and should be - platform specific.
Whether you should do this will depend on other factors such as your fluency with each language, the choice of frameworks and libraries, and the likelihood of porting. Audio processing would be a natural candidate for such an approach though.
Some detail about the samples
Don't worry if you can't get the code to run (the openCV framework can be troublesome...) the main thing is to see how the code is pieced together. I've tried to keep the examples very simple.
The C++ code was ported from C++ samples included with the openCV distro: squares.cpp and stitching.cpp. I tried to alter these as little as possible in order to assess this idea of portability.
Roughly, I had to address two issues...
1/ removed any UI code (so we are just sending data back to the obj-C side).
2/ modify the main() function so it becomes a callable function from the obj-C side. In the .cpp header file I declare a simple class with a single static function to facilitate this. Obviously there is scope to get much more elaborate but this should be enough for you to get the idea.
Hey so for one of my c++ projects I need to develop a 4-5 window application.Now the issue is that currently all of my programs tasks are divided into classes, and I have tested them by passing 'dummy' values and returning print results. That's all fine and working, however now as I want to introduce a GUI interface it presents me with the problem of how my processing should communicate with the front end, since winAPI is initially meant for c and not object oriented language.
What I am thinking of doing, and have a feeling is going to be a tedious task, to make a class which does the win api's registrations and methods for me. Is there any other alternative to this ???
I was looking at integrating Qt into eclipse but I think they stopped providing the library for eclipse, because I couldn't find a download for the library anywhere, not even on the Qt download page.
Well, if you want to use Win32, then you have to do all the stuff that Win32 needs you to do. It's a rather low level API, so you just have to take care of a lot of details.
However, don't over-engineer things. You don't have to write a generic C++ wrapper for Win32... you just have to make a GUI for your program.
If your problem is only that classes are not supported by C, then simply replace the keyword class with the keyword struct. Just make sure to declare the access types of all variables (private, public, protected), that way it becomes interchangeable (Works for both). The only difference between them is the default access type, which for classes is private. In case you used other syntax that is unique to C++, then this wouldn't work.
There are code generators from C++ to C as well. The optimal solution would be to create a GUI using an IDE specifically for that purpose which uses C++ as its base language. MFC works well, but it is not open-source and you will need a considerable knowledge on inheritance and comfort with "class typecasting". Using the included wizards in Visual Studio will help.
Try the first option; it will possibly work the same way.
I recently asked this question https://softwareengineering.stackexchange.com/questions/129076/go-instead-of-c-c-with-cgo and got some very interesting input. However there's a mistake in my question: I assumed cgo could also be used to access c++ code but that's not possible. Instead you need to use SWIG.
The go faq says "The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. "
my question:
Is it possible to access high-level c++ frameworks such as QT with SWIG + Go and get productive? I'd like to use Go as a "scripting language" to utilize c++ libraries.
Have you any experience with go and swig? Are there pitfalls I have to be aware of?
Update/Answer: I've asked this over IRC too and I think the question is solved:
SWIG is a rather clean way of interfacing c++ code from other languages. Sadly matching the types of c++ to something like go can be very complex and in most cases you have to specify the mapping yourself. That means that SWIG is a good way to leverage an existing codebase to reuse already written algorithms. However mapping a library like Qt to go will take you ages. Mind it's surely possible but you don't want to do it.
Those of you that came here for gui programming with go might want try go-gtk or the go version of wxWidgets.
Is it possible? Yes.
Can it be done in a reasonably short period of time? No.
If you go back and look at other projects that have taken large frameworks and tried to put an abstraction layer on it, you'll find most are "incomplete". You can probably make a fairly good start and get some initial wrappers in place, but generally even the work to get the simple cases solved takes time when there is a lot of underlying code to wrap, even with automated tools (which help, but are never a complete solution). And then... you get to the nasty remaining 10% that will take you forever (ok, a really really long time at least). And then think about how it's a changing target in the first place. Qt, for example, is about to release the next major rewrite.
Generally, it's safest to stick to the framework language that the framework was designed for. Though many have language extensions within the project itself. For example, for Qt you should check out QML, which provides (among many other things) a javascript binding to Qt. Sort of. But it might meet your "scripting" requirement.
A relevant update on this issue: it is now possible to interact with C++ using cgo with this CL, which is merged for Go 1.2. It is limited, however, to C-like functions calls, and classes, methods and C++ goodies are not supported (yet, I hope).
I need to build a C++ library to distribute among our customers. The library must be able to be accessed from a wide range of languages including VB6, C++, VB.net and C#.
I've being using ActiveX controls (ocx files) until now. But I wonder if there is a better kind of library (dll, etc.) that I can build. What do you recommend?
I'm limited to C++ as the library language, but you can mention other languages for reference to other developers.
P.S. Sorry if the question was already asked. I had some trouble finding a suitable title. Feel free to correct my English.
Edit: Seems like the best choice is either DLLs or OCX (i.e., COM), but I'm still having some doubts on which one will I choose. Which one is more suitable to modern languages (.NET for instance)? Which one would be easier to use from an end developer perspective?
Almost every language has a way of loading dynamic libraries and accessing exported C functions from them.
There is nothing preventing you from using C++ inside the dll but for maximum portability, export only C functions.
I have some more about this in this post.
If you're looking at supporting both VB6 and .NET, you're pretty much stuck with exposing interfaces via COM, but at least that'll get you out of having to create more than one wrapper based on the language/runtime system you're trying to interact with.
If there is any chance this will need to be ported to non windows platforms then a DLL / Shared library is your best choice as a COM object really isn't at all portable.
In addition you can call a DLL from almost any platform even if it requires you to write a wrapper of some kind. It's pretty easy to wrap a dll in a com object but if you make a native com object it's a lot harder to add a C style DLL API. Plus you might want to call it from java for example and it's much easier to write a JNI wrapper to call your DLL than get it working with COM in any kind of cross platform way.
Really it depends on what platforms you really need to call it from and how certain you can be that you won't get something out of the ordinary in future.
To be callable from all those languages your only real option is going to be COM, without having to write wrappers where required (which would defeat the point)