CODEWITHSUNDEEP
c++dll
sivabudh
sivabudh

Reputation: 32635

Unmanaged C++: How to dynamically load code?

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:

  1. Is dll (dynamic-link library) the answer to this type of requirement?
  2. 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?
  3. 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?
  4. (OPTIONAL) Are there some unforeseen problems that I might encounter?

Upvotes: 1

Views: 788

Answers (3)

Florin
Florin

Reputation: 73

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.

Upvotes: 0

peterchen
peterchen

Reputation: 41096

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.

Upvotes: 3

Denis K
Denis K

Reputation: 1468

  1. Yes, it is. But there are many issues.
  2. 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.
  3. Yes, this will help with loading dynamic libraries, but not with problems in (2). Althought, these problems mostly windows specific.

Upvotes: 1

Related Questions