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.
Related
Here is the scenario:
My swift app collects data from bluetooth and should process them in real-time. These data comes mainly from IMU(gyroscope, magnetometer and accelerometer).
Algorithms that process all of that is going to be written in c++ and utilize some libraries like Eigen. How should I approach such problem? From what I've found:
1) put c++ files into my project, write wrapper in objective-c and bridge it to Swift. Also now sure if I can include Eigen in mobile app easily. This would be tedious process I suppose
2) Get all algorithms as library( .dll, .lib and call it directly from swift, not sure if it's possible)
3) Rewrite all algorithms to Swift, utilize Eigen substitute for Swift, not sure if anything like this exist. Also, this solution is less efficient and would probably fail because of deadlines.
How should I approach such problem? How to solve it in a most efficient way, where I can make use of already exisiting c++ code?
I believe some of you would see this question as opinion based, but I do not know how to state this problem in a way that excludes any ambiguity.
How to run c++ files that uses Eigen in iOS app written is Swift?
Thanks in advance
You cannot call c++ from Swift. However, you can call c++ from objective-c++. And you can call objective-c++ from both Swift and objective-c.
Just make sure that your public-facing #interface code (in the .h file) contains only objective-c. (no classes, no templates, no namespaces, no including c++ headers).
Your #implementation goes in a file with extension .mm which will compile as objective-c++ - giving you an objective-c interface with the full use of c++ in the implementation of the Objective-C object.
c++ objects live quite happily as the member variables of an objective-c++ implementation. However, they will be default-constructed then the objc runtime calls Init. If you are using objects which don't have default constructors, you will need to either wrap them in a boost::optional or a std::unique_ptr (etc).
You can them import the objective-c objects into your Swift program.
Full example for anyone who has not done this before:
https://github.com/madmongo1/swift-to-cpp-demo.git
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'm working on a fairly large project written primarily in C++ using MFC. We are tasked to gradually port this application to use Qt. Years ago, a wrapper around much of our functionality was written using COM. I feel using the COM wrapper from the new Qt code will help isolate code that would force dependencies on MFC. Unfortunately, we're also being asked to ween our use of COM/ActiveX. So, introducing new consumers of our COM wrapper in Qt isn't ideal. Visual Studio has a class wizard that will generate a C++ class based on an interface in a TLB file, but it's dependent on MFC and the interface still exposes COM (LPDISPATCH, SAFEARRAY*, etc).
With all that said, does anyone know of a tool (free or commercial) that will take a Microsoft IDL file and convert it to C++, who's interfaces aren't dependent on MFC nor COM?
and working with the code generated by midl.exe
That's hang-up number one. Midl.exe does not generate code, it only generates declarations. Pure virtual classes in C++, only method declarations with no implementations. Either to a .h file or to a .tlb type library file. The type library is handy because it is easy to read by tooling, having a restricted sub-set of COM called Automation. And implemented by just about any language runtime on Windows.
Key point is that these are just declarations, the glue that makes code written in different modules and/or different languages or class libraries work together. Very important in large projects, interfaces tie the pieces together.
Our system architect learned of our approach and advised that we find a way to not add these COM-specifics to our new Qt projects.
That's singularly unhelpful advice. "Don't do that" is something my doctor tells me when it hurts to put my arm behind my back. I can live with that, I have a good alternative and can just turn around. In your case I would have to demand more from the architect. He's messing with the body parts, he's separating the torso from the legs and head and feet and hands. Brain utterly disjointed. The very glue that makes the different chunks of code you have now work together. Break that interface and you'll seriously break your app, Netscape style.
Beware of the astronaut architect (another Spolsky favorite) that's happy to force you into something that he understands but doesn't have to implement. Demand a reasonable alternative, an architectural approach since breaking the interfaces has a deep architectural impact on your app. Those MFC classes that everybody implemented from the interfaces are pretty much junk when you change the interface. Rewriting them all into Q classes is going to seriously keep you unproductive for a while. And is devastatingly boring code to write. Only to produce the same thing, with more bugs. Things You Should Never Do, part 2.
If you are able to keep using Visual C++, a solution would be to use the plain compiler support for COM.
You need to #import your TLB file
http://msdn.microsoft.com/en-us/library/8etzzkb6%28v=vs.100%29.aspx
Then you can make use of the COM compiler support to handle the COM object instances,
http://msdn.microsoft.com/en-us/library/h31ekh7e.aspx
I think I understand how Objective-C++ works in relation to Cocoa, and I am fairly versed in the basics of command-line C++ but sort of afraid to try mixing it with Objective-C. I can create a GUI with Interface Builder in Xcode, and even make classes (.h and .m files) for the interface automatically. The outlets, maybe actions (I still get those confused) leave the curly brackets open to put your own code in. So could I just put C++ code in those brackets to to take input from those buttons (and see the output, etc.)?
I guess if this is the case, one wouldn't have to learn any Obj-C, as long as they knew where to put the C++ code! Am I wrong?
Also, could anyone help me figure that out or at least point me somewhere I can learn more about this? This topic is fairly scarce on the web and I don't understand Apple's documentation.
My suggestion would be to have Objective-C files in your project (the .m file), then keep your Objective-C++ in separate files (as diciu mentions, .mm files).
One strategy would be use to these Objective-C++ classes simply as wrappers over C++ classes: write your code in C++, in .cpp files like normal. Then, when you need to access some functionality from your C++ from an Objective-C file, write a wrapper Objective-C++ class and call that from your Objective-C.
This last bit feels like a lot of work for small projects, and it is, but if you have a lot of C++ that you need to use, and a comparatively little bit of Objective-C to write, this works pretty well. (Imagine a situation where you are writing a Cocoa interface for a well-factored Windows or Linux program: where all the application logic was written in a platform agnostic manner, and you "just" have to write the UI in Cocoa to get it running on the Mac.
But, another reason for doing this wrapper approach is that Objective-C++ is a hybrid language, so has limitations as to what it's capable of, in both directions.
The thing you need to understand about objective-c++ is that the name is a lie. or at least implies a lot more than you might think.
Objective-c++ does not mean you can write hybrid objective-c++ "objects". It means that you can use c++, and objective c, in the same file. they can reference each other directly - the cannot inherit or derive from each other.
Rename .m files to .mm and you will be able to write (Objective-)C++ code in them.
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).