I'm developing an ios app that's very basic and uses objective almost all of the time. However my app needs to deal with big integer numbers (eg: 2^200) and add and multiply them. To achieve that I need to include a c++ library called bigint that allows these operations on huge integers. The problem I have is that when I include the bigint project I get many errors and I thought that this could be because it's c++ and can't mix with objective c. I'm new to this idea and was wondering if there are any steps i need to take to correctly add a c++ library to an objective c project. By the way I'm not using opengl or anything complicated just simple ui and some quartz stuff.
Update:
I did everything you guys said, I changed all the extensions to .mm and added the bigint library. My project ran perfectly without errors before doing these things. I get an error when i do this and I get an error even if I don't even add the library. just changing the file extensions to .mm gives me the following error.
This just doesnt make sense since everything ran fine before and I don't have any duplicates in my program. I have no idea why just changing the extensions to .mm could cause this error. Any ideas guys?
You can mix in C++ files, but use a .cpp suffix for them (and .hpp for their corresponding header files). If you want to mix C++ and Obj-C in the same file, you can do that, but give it a .mm suffix.
Related
I'm trying to write my first game in c++, and I want it to dynamically load everything from files. This includes the enemies, and I was wondering if there was a way to dynamically include their code at runtime, instead of linking the on compile, so that the levels are easily interchangeable. Lua might be an option but I have no clue where to start, and dll seems to be Windows-only (and I wouldn't know where to start there anyway). Can anyone help with this?
tl;dr I want to link in code to my c++ game at runtime.
For the Lua approach you first need to choose the version first. Right now there is the major version 5.1 and 5.2. My previous work was using 5.1 and for my new project I decided to update to 5.2, however I found that my favorite script wrapping tool (SWIG) does not work with 5.2. Just something to decide at the beginning, because you do not want to get a version working and then have to change it.
Lua comes with makefile build environment. My first experience of trying to build on Windows was a bit of a nightmare, did not appear to just run out-of-the-box, so I opted to create my own Visual Studio project at the time, and just include all the .C files in the project. There are two files which need to selectively included/excluded depending on how you intend to compile: lua.c and luac.c. If you are planning to embed Lua in your app, then exclude both of these files; they both contain a main() function and are designed to build console apps. Include all the rest of the C files in your project.
You should be able to compile easy from this point.
When you include the headers of Lua, keep in mind that the functions are C functions so if you are including them from C++ you need to wrap the file inclusion inside of: extern "C" {} - example: C++ Lua 5.1 Issue
Wrapping your interfaces in another topic and there are lots of resources available. My favorite is SWIG but there are lots of options, including hand coding the conversion of your C/C++ -> LUA -> C/C++ code. Would recommend just focusing on getting the first part working first, get the interpreter embedded so that you can run a "hello, world!" script from Lua inside your app.
So going by your requirement of crossplatform use and dynamic linking, what you're probably looking for is an environment like QT which has QLibrary: https://stackoverflow.com/a/9675063/453673
But https://softwareengineering.stackexchange.com/questions/88685/why-arent-more-desktop-apps-written-with-qt
MingW is the open-source equivalent for Visual C++, so it can help you writing code for Windows (though if I had a choice, I'd directly use Visual C++). The way dll's are loaded in Windows is somewhat similar to the way they're loaded in Linux, so you'll be able to write code with #ifdef's to do conditional compilation. I've written one such program a couple of years back.
To load a shared library(always with .so as suffix) under Linux, you could use dlopen(), dlsym() and dlclose()
I have some C++ code (exposing a C-only interface through a header) which I will use for an iOS project.
I can either create a static library and link to this from my app project, or add the source files directly to the app project - which option is best?
All answers appreciated!
Add the sources if you expect them to change often. Otherwise a library will be more suitable and will make your project cleaner (however, you will have to put only the header files in your project)
I've used OpenCV in one of my app projects which is mostly written in C++. I've found that adding the source files to the app project worked better for me because I made some minor changes to the code wherever appropriate. Comes down to the use case basically.
I always prefer to add the source if I have it, simply because it makes debugging easier. If you're making a call into a library routine and getting back an unexpected result (or crashing, or whatever), it's much easier to step into the library code with the debugger and figure out what's going on. If you just have a static library, it's a black box and you can't see what's going on inside. It also allows you to change the library code more easily if you encounter a bug or a missing feature (just be careful if the library is shared among other projects, to make sure you keep the library code up to date in its own repository).
Xcode is good about letting you keep your project organized, so use those features to your advantage. Keep the library code and headers separate from your main application and link it in as needed.
I suppose by code you don't mean a well formed library, so I expect this code could get any kind of modification pressure in the future. The best way is then wrapping it. here is one very nice example, but you might do it differently: http://robnapier.net/blog/wrapping-cppfinal-edition-759
sorry for my english is not good.
I'm trying to use pure c++ code in my iOS project but I have the next issues:
I create one new file product.cpp + product.h, I create his own methods and atributes, and I want to use this class in my viewcontroller.m but dont run, I change the extensión of the viewcontroller.m to viewcontroller.mm but dont run but if I change the extension of the appDelegate.m to appDelegate.mm this is ok and run.
My question is I always have to change mi files to .mm if I want to use .cpp?
:/
Generally yes, a file extension of .mm tells Xcode to invoke the Objective-C++ compiler, whereas .m tells the compiler to invoke the Objective-C compiler. You can set the compiler type on a per-file basis using the file-settings pane on the right (so you could force Objective-C++ compilation on a .m file), but this is non-intuitive and is likely to confuse future maintainers.
If you're willing to consider some advice from a long-time C++ and Objective-C user, I've done a lot of mixing of the two and over time it's more trouble than it's worth. You're much better off if sticking purely to Objective-C, and if you have some C++ library that you just have to integrate, then make a C wrapper for it.
It used to be the case that Xcode analyzer only worked on Objective-C files, not Objective-C++, so you'd lose a lot of the value that tool provides by writing Objective-C++ files. I'm not sure if Apple has changed it in the year or so since I last wrote any Objective-C++ but I imagine there isn't a lot of reason for them to. Stick with Objective-C if you can because the Analyzer is extremely helpful.
I have some legacy code to reuse written in c++ with opengl but most of the examples online are written in objective c... so porting my code would be probably easier in a mixed env.
I would prefer to avoid a "library" solution with separated .so
Yes you can. Just add your c++ code in a file called *.cpp
You can even mix C++ and objective-c code in the same file, but make sure the file is named *.mm (instead of *.m). That's a gotacha that a lot of people fall far.
Considering you want to use some legacy C++ code, this is probably exactly what you are looking for: Sample code from Apple for Cocoa With Carbon or CPP
Yes, you can use both in a single project. If memory serves, the extension for "Objective-C++" files is .mm.
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.