I have paid for an expensive .dylib file however, the code is non objective-c in short, horrendous! I am thinking of creating a wrapper of some sort like an API to make interfacing with this .dylib nightmare free. How is this done? Here is what I was going to do:
Create a customDylibSDKWrapper .h and .m file, and have the appropriate function names that will keep things simple, and in the .m file, add all the c++ functions inside each objective-c function. So then all I would need to do in the future is, call the objective-c function and that will automatically call the C++ code.
Is this the correct way of creating a wrapper?
If it is, this does not create a private hidden wrapper, all the code will still be visibile. Is there anyway to package the .dylib file along with my objective-c .m files exposing only the objective-c .h file?
If anyone is curious to see the horrendous code feel free to look at this link: link to hard to decipher code
You can create both a dynamic library and a static library with Xcode.
Creating dynamic libraries isn't officially supported, and it requires editing some XML, and apps that include dynamic libraries won't be approved by Apple, so I'm not going to bother with dynamic libraries in this answer.
You can however easily create static libraries.
Step one: start a new project, being sure to select Cocoa Touch Static Library when you create the project:
Step two: Write your code.
Step three: Push the run button. Since your static library should have any code that will actually run, nothing should actually run. Instead, Xcode builds the library.
In the view on the left that shows all your folders and files and such, you should see a .a file, which is the compiled library. You can find on your computer by right-clicking and clicking "Show in Finder".
Now all that's left is distributing the .h/.a files to whoever you want.
Related
I am trying to learn C++ from some Stanford Course and they have a custom library which contains a bunch of header files(.h) and their associated source (.cpp) files.
I want to create new C++ projects in xcode 6.x to try out code and include those custom header files in my new projects.
I have no freaking idea how to include those files in my project so that i can peacefully #include "blahblahblah.h" and use functions from that header file without issues.
I am new to both xcode, c++(although i know some coding part) and anything else with this process.
Summary:
I have a folder Library which contains a series of .h and .cpp
files.
I have XCode 6.x.x/Eclipse installed.
I want to create a new C++ project and use #include
"OneOfThoseHeaderFiles.h" and then use a function or something from
those header files.
Also assume i have no clue how to run some command line codes that i see a lot of.
If someone can please tell me in the most simple way(preferably step-by-step) i would be so eternally grateful and sing praises to you until the day i die :)
Note: Either XCode or Eclipse is fine. I really just want to start coding.
I have spent the better part of a whole week trying out xcode, eclipse etc and trying to follow a ton of steps to get it working but i just cant get how to add the files without issues. Either the info seems to be for Xcode 4.x and every menu seems changed or the suggestions are so complicated that a novice like me cant figure it out.
First off, almost all the information for Xcode will be available on the Apple Developer's portal:
https://developer.apple.com/library/prerelease/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/start_project.html#//apple_ref/doc/uid/TP40010215-CH2-SW5
To create a simple static library on Xcode 6 you start by creating a new project, then under OS X - Framework and Library select Library, on the next window change the Framework to None (Plain C/C++ Library) and static (since that is what your are stating).
Once your project is created, add the existing headers and sources to your project, either by dragging them with the mouse or with the add files drop menu from the right click functionality, you can create a new group in Xcode if you want some order for them.
When adding the files, on the add window shown you can select to either copy them or use their current location.
If needed you might have to change the "header search path" in your target configuration under "Build Settings", if it is the first time you are using Xcode some of this will sound weird but I am sure you will find most of it on the Apple Developers portal in great detail.
If you want to test the files without having to create an external static library you could create a command line project and test them faster and easier.
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
I would like to create a static library in C++ to store my functions.
I'm aware this question has been asked on the Cplusplus forums but I could really use a
more accurate description of what to do.
As far as I'm aware you create a new Win32 program and then add the header file (.h) and the
code file (.cpp).
So in fact I have a few questions.
1 - How do I put my code into these files?
Do I use the .cpp?
2 - I did manage to make a simple library with an add function alone, but after compiling
and building it I was unable to #include it in a program. Why is this?
Could someone please write out a step-by-step approach to making this so I can finally do it.
I am aware MSDN has a tutorial for this, and I have looked at it.
The thing is it uses a OOP approach to making the static library, and the calls to the
functions within the library use the :: operator (think its an operator), too often which is what I want to avoid.
Would like to start simple, basically.
Thanks for any help given.
The idea of a static library, is that you write your code as usual, but you compile it as a static library. The users of a static library still need your header files, but they don't need your .CPP files anymore, because the actual implementation is contained in your static library file.
To use a library, you include the header files you need, and then link the library file with your program.
Here is a link to the microsoft walkthrough.
http://msdn.microsoft.com/en-us/library/vstudio/ms235627.aspx
How to create and use a static library using Visual Studio
Here is excactly how you do it in Visual Studio 2012.
To create a library, create a new C++ project. In the wizard, at Application Settings, choose Static library. Uncheck Precompiled header.
Create your library as you want. Don't forget to declare everything in header files.
Compile the project as you usually would. This creates a .lib file in the debug folder of your solution
To use the library, create an application as you usually would.
To link the library with your project, drag the .lib file to your project in visual studio.
To let visual studio find your header files, right click your project. Choose Properties->Configuration properties->C/C++. There is a input box called Additional Include Directories. Here, you have to write the path to the header files of you library.
You can now use the header files as if they where made by your project directly. The implementation of your library is taken from the .lib file, and everything should compile and run well.
Another option, is referencing the whole libary project in your application. To do this, you must get the library project in your solution. Right click your solution in Visual Studio->Add->Existing Project. Then you have to reference the project. Right click your project->References->Common Properties->Framework and References->Add New Reference->Choose your project. Now you can edit your library in this solution and use it directly in your application.
This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
So basically, I am attempting to write my own GUI wrapper in Python (Using GTK+, but I don't think that's relevant) for an API that is written in C++ and compiled by the user into a shared object file (in linux [*nix? I'm not quite sure how it works on macs]) or a dll (in windows) that you should be able to reference to use the API yourself. After quite a while of trying with Cython, I am able to write my own extensions, as long as it is only a single file, but I can't find anything online about using multiple files (as this obviously is, since any real project would be) to compile into a single .so that can be imported into a Python project. Would I need to manually go through and use Cython and create .pyx files for each .cpp file (there are a lot of them), compile those into cpp files and then edit then use the make file to compile those into the .so file, or is there a more automated way? (p.s. I tried compiling each one separately with Cython, but it didn't seem to like the "#include < path/file >" notation and so couldn't compile most of the files)
Other info: I have been able to interface with the library using ctypes, but that felt extremely hackish and un-pythonic, and I want to get some more experience with Cython anyways, since it seems like it could be an extremely useful asset to have.
You could do a file named "yourmodule.pyx", rename all the others files to pxi, and do:
include "other1.pxi"
include "other2.pxi"
Then you'll have only one file to cythonize and compile: yourmodule.pyx.