I have some function module written in Objective-c, could i wrap the objective-C by C++, then integrate C/C++ code with Lua using toLua++, then using the lua code in Corona? Could i do that? It seems impossible...
Corona doesn't allow extending with native code (yet)
It is in their roadmaps, and it is supposed to be implemented in coming months
you could make a shared library, then just require it into your code.
e.g. create mylibrary.so
then in lua
require("mylibrary")
lua will look for it in your LUA_PATH.
There are a few things I'm not sure of in corona - if it will load a shared library and you can use toLUa++. It will work fine in normal lua. You might have problems with bindings in the shared library to Cocoa - not sure, not something I've tried. I've built a .dll in windows and it worked fine - again not in corona.
Here's how to build a shared library
It seems like corona will do it - have a look here
this could be the stopper though - no shared libraries on iOS
hth
Related
I have a shared library "mylib.so" which was written in C++ and I would like to make an application in Ruby that calls the library functions.
I researched and found FFI (https://github.com/ffi/ffi) and it only works with a C library. With Rice (https://rubygems.org/gems/rice/versions/2.1.0) only I found tutorial that I need to change the source code of the library, but I do not have access to this code.
Is there any way to implement a C++ library in my Ruby code to use its functions?
When you say you don't have access to the code, you mean that you do not have access to the headers of the library? If you do not have access to the headers defining classes, prototyping functions and exposing some API, then you wouldn't be able to actually bind this library to any other segment of code, whether the latter is written in c++, python, ruby or whatever.
If you do have access to the headers of the library, then you can easily use rice-ruby to build a ruby wrapper - by following the instructions here. You need only the headers and an up-to-date version of your library in order to do a proper wrap. Feel free to better define your problem and I'll try to help.
I have a bunch of python code that I would like to "compile" into a shared library with a C interface that can be linked with other C/c++ programs and work without depending on too many other libs (perhaps python and some other dlls but they should all be included into a directory with the final lib).
I don't really want to rewrite the python code into C++ for this. I can of course, but it would be best to have a standalone lib that can be used like a dll/so lib.
I have tried cython and wanted to compile python to C and then just compile C code into a dll but that doesn't seem to work quite yet (I haven't been able to make it work flawlessly yet). And then I also tried bbfreeze - but does bbfreeze support creating an .so file? Wasn't able to find out how to do it. Does anyone know?
Do you know of any other options that are more straightforward? the python code only needs to be compiled once. And best of all would be if it creates a single .so file no matter how big it is that just works without too many dependencies.
You can use Python as a library from inside your C++ application: it's called the Python/C API.
The idea is that you initialize your own interpreter, then you load a script in it. You can expose your C++ objects through global variables or modules inside the Python interpreter for your code to interact with, your you can just run Python functions directly from your C++ code.
Now, I understand that you might want to have your Python scripts embedded inside the shared library: this is not necessarily an easy task, with the traditional GNU toolchain. There are multiple techniques to achieve this, but none is official, and all seem way too complicated as opposed to just having the script in an external file.
If your goal is to hide the scripts from the end-user, you could sign them or encrypt them with a private key and embed the public key inside your library, but keep in mind that the key can easily be retrieved by anyone with enough motivation.
I was just wondering what my options were for cross-platform implementations for the dynamic loading of plugins using shared libraries. So far the only one that I have found is:
http://library.gnome.org/devel/glib/stable/glib-Dynamic-Loading-of-Modules.html
And I was just wondering if I had other options? Essentially, I want to be able to put plugins in shared object files, and load them at runtime and I wanted to do it in a cross-platform C++ way.
Edit: I found this Dr Dobbs Post from 2007; surely somebody has come up with something more since then.
You could look into Boost Extension, though it has not yet been accepted into Boost.
The Boost.Extension library has been
developed to ease the development of
plugins and similar extensions to
software using shared libraries.
Classes, functions and data can be
made available from shared libraries
and loaded by the application.
Qt has a nice plugin system. You should take a look at the second part of that page.
If you want something simple and lightweight try: https://pocoproject.org/docs/package-Foundation.SharedLibrary.html
Using the SharedLibrary class it takes three lines to call a function in a C shared library:
Poco::SharedLibrary lib("libfoo.so");
int (* foo)(int) = reinterpret_cast<int (*)(int)>(lib.getSymbol("foo"));
printf("answer %d\n", foo(5));
I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.
I'll preface this by saying I'm a C# programmer who inherited horrible code with no documentation. I have an unmanaged C++ library wrapped with managed code that worked fine in VS2003 with .Net 1.1 Framework. I'm trying to get it upgraded to at least .Net 2.0.
I have the unmanaged C++ library that was compiled with "MSVC 8.x" (thus equivalent to VS 2005, I assume). I've been trying to migrate everything to VS2008 and still have some issues with this library at runtime.
My question is this: should this library work with VS2008? Or should I be developing in VS2005 if the library was compiled with VC8.x?
Any thoughts would be greatly appreciated. Thanks!
It should work, I expect that you are having issues with your marshalling. It is probably stuff that was declared incorrectly for PInvoking that managed to work in .NET 1.1 but not in later versions.
You don't say what sort of problems you are having at run time, nor do you state how you access your library. For example, do you compile your library along with your project? If so, can you turn on unmanaged debugging in your C# project and step into the code you are having trouble with? How are you calling the unmanaged code? Is it through PInvoke, or do you have managed C++ wrappers?
In my experience, the best solution for calling out to a legacy unmanaged library is to add a managed wrapper library for your legacy library written in managed C++. This way you present a managed interface for your library for all .NET languages to consume and you don't have to worry about getting your PInvoke signatures correct.
Your project should look something like this.
C# Application -> Manage C++ Wrapper DLL -> Legacy DLL
It can depend what else the lib relies on. For example, if you are using the STL across the library interfaces then it would be a bad idea to have the library compiled with a different version to the client. However, if the library presents a simple C style function interface then you shouldn't have problems.
If you have the source code for the library then I would recommend trying to port it to VS2008. In general it is much less hassle in the long run to have everything in the same development environment.
How are you wrapping the unmanaged lib ... presumably using managed extensions for C++ if it dates back to VS2003. This is now deprecated and has been replaced with C++/CLI as of VS2005. Whilst the newer compilers support a /clr:oldSyntax switch to still compile the old code there are definitely issues with it. We have old code that will not compile on VS2005(8) using this switch.
--Rob Prouse:
The wrapper uses managed C++, no PInvoke. The wrapper is compiled into a DLL that is then used by another application (as you illustrated).
The legacy code produces graphics objects. When I try to get the handle to an image, I get a null exception instead. The debugger doesn't let me get farther into the code to figure out why. Everything else seems to run ok - the other data objects needed to create the image exist and appear to be correct. (Sorry, I know that is still a pretty vague description.)
--Rob Walker:
I unfortunately do not have the source code.
Not sure about "using the STL across the library interfaces". Does graphics fall under that category?
I was able to get my application to run with using the /clr:oldSyntax switch, but that's where I get the null handles to images. I tried to put in all the modifications so that it would compile with /clr, but then I kept getting link errors that I couldn't resolve. (The linker kept complaining about not being able to find files even though those files were in the folder where it was looking.)