I know that when you load a dynamic C++ library using dlopen() you can then get pointers to functions inside that library, but is there a way to efficiently (performance matters) do it the other way?
I know that I could just call a function (when initializing the library) inside the library passing an array of pointers to functions, or just send the pointers all separately to a function. (although an array would probably be better because it allows me to add functions yet not require all old plugins to update)
I'm not really sure if this is efficient as there might be hundred functions and sending all of those to maybe 10 libraries might not be efficient.
But I am not very experienced with Dynamic Libraries so I am just wondering if you guys know of any better was to do this.
EDIT: Maybe put all those functions in a class and then send a class pointer trough a function call? Would that work?
"But I am not very experienced with Dynamic Libraries"
That's the cue to say: you don't want to do this.
Perhaps look at Boost Extension (not official part of boost), which takes the high-level, C++ approach here.
That said, most platforms support this to an extent. E.g. XlC++ on AIX has rtld (which requires an explicit 'exported' symbols map, IIRC), and I had the same working on windows and linux (our 3rd-party workflow engine required it). Sending the array of fptrs seems most pragmatic, and closer to the 'plugin' pattern.
Related
So for the past few hours I've been trying to figure out how to use C++ classes contained in static (or dynamic) libraries from within Lua. I've found several packages, such as LunaFive or SimpleCppBinding, but I seem not to understand how to use them properly. From what I see there's a main function, therefore I guess it's not a library, but an executable which I run and then run the Lua script, which will hook the app and get the class, or something? What I basically want to do is:
create a library containing, for example, a class 'Player' in C++
modify this library to be usable from Lua
somehow use this class and it's methods from within the Lua in the same way as if it would be a Lua class
Is such thing even possible? And if so, could someone explain how such thing can be done?
I'm currently on Windows, but I can do it on Linux as well. On windows I'm using VS, on Linux I'd be using CLion paired with g++. Lua 5.3.
I'm not sure if this is somewhat relevant, but I'm developing a game-mode for FiveM (GTA V multiplayer client). The FiveM comes with a Lua support for scripting by default, but I'd love to use some of the C++ standard libraries and features. Therefore I'd really love to create some libraries for the server in C++, and then use them from within the Lua supplied by FiveM.
Static library: not possible. Your options are: 1. a dynamic library (binary) with some kind of interface accessible by Lua executable (Alien, Lua-specific hooks....) or 2. A custom executable which includes the Lua engine and the C++ stuff with some glue. Your examples with the 'main' function probably are the latter type.
Lua was designed, from the beginning, to be integrated with software written in C and other conventional languages. This duality of languages brings many benefits. Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software.
-Preface
I understand your pain, however Lua simply isn't meant to be used the way you intend, it's actually built to be used the other way around.
The closest thing I can think of to get the result what you want is to have a host C++ application from which you immediately create a lua state and push results of the functions you called from the C++ program into the stack, in return can be used in your Lua script and processed.
If this is something you might be able to adjust to, here is a great starting point
I have a library written in C++/CLI and I want to open it up. I want it to be as cross-platform as possible and be able to write bindings to it for other languages to use (Java, Python, etc, etc). To do this, the library needs to be in plain C++ for maximum flexibility. I figure that the logical structures are already there, I just need to replace the .NET libraries it uses with the standard C++ ones. Is this a misguided notion? What should I watch out for when making this transition?
It might be more trouble than it's worth. Here is what you might come across:
There is no garbage collection in C++. This is the big one. This may require a significant redesign of your library just to convert. If you are using at least C++ tr1, or the boost library, you can sort of get there by using shared_ptr, but there are important fundamental differences. For example, you must be wary of circular dependencies. Also, they make debugging difficult without specific support for them in the debugger.
Functions in .Net classes which have no equivalent in C++ stl or the standard library. Probably the biggest hurtle will be any string manipulation code you have written since there are lot of differences there.
Class libraries/assemblies are not built-in to C++ - every platform has its own method of creating dynamic or shared libraries, and there isn't much support for C++ shared libraries - only C libraries in many cases. Be prepared to make everything a static library.
You must manage all your resources yourself.
Never done a port of C++/Cli to C++, but this comes to my mind:
Make sure that you dont have memory leaks. Use smart-pointers instead of gcnew, if possible (if not, make sure your code is exception safe nontheless).
Make sure your libraries interface only consists of builtin types (builtin does not include types of the STL! however this is not coercively necessary if you go open source)
Our industry is in high-performance distributed parallel computing. We have an unmanaged C++ application being developed using Visual Studio 2008.
Our application (more like a framework) is supposed to be able to dynamically load code (algorithms) developed by 3rd parties (there can be many dlls) that conforms to our interface specification, and calls the loaded code to get some results.
Think of it like you want to call a sin(x) function, but there are many different implementations of sin(x) that you could use.
I have a few questions as I'm very new to this area of dynamically loading code:
Is dll (dynamic-link library) the answer to this type of requirement?
If the 3rd-party used a different type of IDE to create the dll compared to mine (say Eclipse CDT, C++Builder, Visual C++ 6.0, etc), would the dll still work with my application?
Our application is supposed to work cross-platform as well (should be able to run on Linux), would using QLibrary be the most logical way to abstract away all the platform-specific dll loading?
(OPTIONAL) Are there some unforeseen problems that I might encounter?
1) generally, yes. If the API gets complex and multi-object, I'd use COM or a similar mechanism. But if you have to manage only a little state, or can go completely state-free, a pure DLL interface is fine.
2) Use a suitable calling convention (stdcall) and data types. I would not even asusme that the implementation has to be in C++. so that means char/wchar_t, explicit-sized ints, e.g. int32 , float and double, and C-style arrays of them.
3) can't say
4)
No cross-boundary memory allocations: free what you allocate, and let the plugin free what it allocated.
Your API design has a big influence on achievable performance and implementation effort. DOn't make the functions to small, give the implementation some freedom how it handles certain things, define error protocol, threading requirements etc.
[edit]
Also, if you declare structures, look into alignment and compiler options to control this (usually #pragma pack). This is required so clients see the same layout.
The compiler usually "mangles" the names for the exported symbols (e.g. add an udnerscore for STDCALL convention). Typically, this is controlled through a .def file that is passed to the linker.
Yes, it is. But there are many issues.
May or may not. Firstly, you should be aware of calling conventions. Secondly, since there is no standardized ABI for C++, you should stick to plain C at interface level (Btw, COM technology was all about this -- making a standardized ABI). Thirdly, each plugin may have its own CRT and so problems may appear, there is a good article about this on MSDN.
Yes, this will help with loading dynamic libraries, but not with problems in (2). Althought, these problems mostly windows specific.
In my experience, QLibrary is the best answer to your questions.
It provides a simple interface and takes care of all the platform-specific details.
Indeed, that means that the plugins must be also written using QT.
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).
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)