I have a third party library as source code. It comes with a Visual Studio project that builds a .lib from it.
I want to access the functionality from C# though, so I copied the project and changed it to create a dll.
The DLL didn't contain any exported functions though, so I also created a module definition (.def) file, and added the functions I need in the EXPORTS section.
This works for all the functions that are declared in extern "C" blocks. However, some of the functions that I need are declared outside of those blocks.
If I add those to the EXPORTS section I get the error LNK2001 unresolved external symbol XYZ :(
I don't want to change the sourcecode of the 3rd party library if I can avoid it.
What's the most elegant and hopefully simplest way to access those functions as well?
Edit
One more point for clarification: As far I can tell there is no C++ functionality involved in the interface I want to expose. I honestly don't understand why the 3rd party authors did not just include the few remaining functions into the extern "C" blocks. These functions are at the bottom of the header file, maybe the person that added them just made a mistake and put them outside of the extern "C" blocks scope.
For C++ one way (IMHO the most elegant) would be using C++/CLI, which is designed for that. Especially if you have not only functions but also classes.
You create a thin wrapper layer which is fairly simple:
Create a CLI class
put a member instance of the original class
wrap all public methods from the original class
Like This (untested):
C++ nativ:
// original c++ class
class Foo {
public:
Foo(int v) : m_value(v) {}
~Foo() {}
int value() { return m_value; }
void value(int v) { m_value = v; }
private:
int m_value;
};
CLI wrapper:
// C++/CLI wrapper
ref class FooWrap
{
public:
FooWrap(int v) { m_instance = new Foo(v); }
!FooWrap() { delete m_instance; }
~FooWrap() { this->!FooWrap(); }
property int value {
int get() { return m_instance->value(); }
void set(int v) { m_instance->value(v); }
}
private:
Foo *m_instance;
};
Here you can find a short howto, which describes it in more detail.
Edit:
From your comments:
[...] I never worked with C++/CLI though and the language looks a little confusing. Since the project deadline is pretty close I'm not sure if there's enough time to learn it. I'll definitely keep this option in mind though!
If you are not looking for the most elegant way, as in your original question, but for the fastest/shortest way: For C++ one way (IMHO the shortest way) would be using C++/CLI, which is designed for that. Especially if you have not only functions but also classes. You create a thin wrapper layer which is fairly simple... Here you can find a short (in 10 min) howto, which describes it in more detail.
Related
I am about to write a C++ framework that will later be used by different C++ applications. The framework will provide one main class, which will be instantiated by the application. That main class will make use of some other classes within the framework. And there will be some helper classes, to be used directly by the application.
Now I am thinking of how I should encapsulate that class framework. I could write the header and source files as usual, and then include those in the applications that will make use of the framework, so that all will be compiled in one go together with the application.
But I am not sure whether this is "the best" approach in my case. Wouldn't it be an option to put the whole framework into a DLL and then link that DLL to the applications? However, I also read that it is often not the best idea to let a DLL export whole classes, and that this approach might lead to difficulties when using STL templates as data members.
Can you recommend an approach to me, maybe something else I have not mentiond above, incl. the pros and cons of all these options?
You can create a C interface using opaque pointers, which is needed in your case because of the varying types and versions of compilers involved. Note that you may not accept or return non-C types, unless you also wrap them in opaque pointers. It's not hard, but there's a bit of work needed on your behalf.
Assuming a class 'YourClass', you would create a YourClassImpl.h and YourClassImpl.cpp (if needed) containing your C++ class code.
YourClassImpl.h
class YourClass
{
private:
int value = 12345;
public:
YourClass() {}
~YourClass() {}
int getThing() { return value; }
void setThing(int newValue) { v = newValue}
};
You would then create a YourClass.h which would be your C header file (to be included by the users of your DLL), containing an opaque pointer typedef and the declarations of your C-style interface.
YourClass.h
#ifdef MAKEDLL
# define EXPORT __declspec(dllexport) __cdecl
#else
# define EXPORT __declspec(dllimport) __cdecl
#endif
extern "C"
{
typedef struct YourClass *YC_HANDLE;
EXPORT YC_HANDLE CreateYourClass();
EXPORT void DestroyYourClass(YC_HANDLE h);
EXPORT int YourClassGetThing(YC_HANDLE h);
EXPORT void YourClassSetThing(YC_HANDLE h, int v);
}
In YourClass.cpp you would define those functions.
YourClass.cpp
#include "YourClass.h"
#include "YourClassImpl.h"
extern "C"
{
EXPORT YC_HANDLE CreateYourClass()
{
return new YourClass{};
}
EXPORT void DestroyYourClass(YC_HANDLE h)
{
delete h;
}
EXPORT int YourClassGetThing(YC_HANDLE h)
{
return h->getThing();
}
EXPORT void YourClassSetThing(YC_HANDLE h, int v)
{
h->setThing(v);
}
}
In your users code they would include YourClass.h.
TheirCode.cpp
#include "YourClass.h"
int ResetValue(int newValue)
{
YC_HANDLE h = CreateYourClass();
auto v = YourClassGetThing(h);
YourClassSetThing(h, newValue);
DestroyYourClass(h);
return v;
}
The most usual way of linking to your DLL would be with LoadLibrary/GetProcAddress - I'd also advise adding a .def file to your project to ensure that the functions are named 'nicely' and are not difficult to access because of any name decoration.
Some issues to keep an eye out for:
Only the standard C fundamental types can be passed back and forth across the interface. Don't use any C++ specific types or classes.
PODs and arrays of PODs may be safe for you to use, but watch out for any packing or alignment issues.
Exceptions must not cross the interface boundaries - catch anything that gets thrown and convert it to a return code or equivalent.
Ensure that memory allocated on either side of the boundary is deallocated on the same side.
After digging the web, I found some reference to a powerful pattern which exploits CRTP to allow instantiation at run-time of static members:
C++: Compiling unused classes
Initialization class for other classes - C++
And so on.
The proposed approach works well, unless such class hierarchy is placed into an external library.
Doing so, run-time initialization no more works, unless I manually #include somewhere the header file of derived classes. However, this defeats my main purpose - having the change to add new commands to my application without the need of changing other source files.
Some code, hoping it helps:
class CAction
{
protected:
// some non relevant stuff
public:
// some other public API
CAction(void) {}
virtual ~CAction(void) {}
virtual std::wstring Name() const = 0;
};
template <class TAction>
class CCRTPAction : public CAction
{
public:
static bool m_bForceRegistration;
CCRTPAction(void) { m_bForceRegistration; }
~CCRTPAction(void) { }
static bool init() {
CActionManager::Instance()->Add(std::shared_ptr<CAction>(new TAction));
return true;
}
};
template<class TAction> bool CCRTPAction<TAction>::m_bForceRegistration = CCRTPAction<TAction>::init();
Implementations being done this way:
class CDummyAction : public CCRTPAction<CDummyAction>
{
public:
CDummyAction() { }
~CDummyAction() { }
std::wstring Name() const { return L"Dummy"; }
};
Finally, here is the container class API:
class CActionManager
{
private:
CActionManager(void);
~CActionManager(void);
std::vector<std::shared_ptr<CAction>> m_vActions;
static CActionManager* instance;
public:
void Add(std::shared_ptr<CAction>& Action);
const std::vector<std::shared_ptr<CAction>>& AvailableActions() const;
static CActionManager* Instance() {
if (nullptr == instance) {
instance = new CActionManager();
}
return instance;
}
};
Everything works fine in a single project solution. However, if I place the above code in a separate .lib, the magic somehow breaks and the implementation classes (DummyAction and so on) are no longer instantiated.
I see that #include "DummyAction.h" somewhere, either in my library or in the main project makes things work, but
For our project, it is mandatory that adding Actions does not require changes in other files.
I don't really understand what's happening behind the scene, and this makes me uncomfortable. I really hate depending on solutions I don't fully master, since a bug could get out anywhere, anytime, possibly one day before shipping our software to the customer :)
Even stranger, putting the #include directive but not defining constructor/destructor in the header file still breaks the magic.
Thanks all for attention. I really hope someone is able to shed some light...
I can describe the cause of the problem; unfortunately I can't offer a solution.
The problem is that initialisation of a variable with static storage duration may be deferred until any time before the first use of something defined in the same translation unit. If your program never uses anything in the same translation unit as CCRTPAction<CDummyAction>::m_bForceRegistration, then that variable may never be initialised.
As you found, including the header in the translation unit that defines main will force it to be initialised at some point before the start of main; but of course that solution won't meet your first requirement. My usual solution to the problems of initialising static data across multiple translation units is to avoid static data altogether (and the Singleton anti-pattern doubly so, although that's the least of your problems here).
As explained in Mike's answer, the compiler determines that the static member CCRTPAction<CDummyAction>::m_bForceRegistration is never used, and therefore does not need to be initialised.
The problem you're trying to solve is to initialise a set of 'plugin' modules without having to #include their code in a central location. CTRP and templates will not help you here. I'm not aware of a (portable) way in C++ to generate code to initialise a set of plugin modules that are not referenced from main().
If you're willing to make the (reasonable) concession of having to list the plugin modules in a central location (without including their headers), there's a simple solution. I believe this is one of those extremely rare cases where a function-scope extern declaration is useful. You may consider this a dirty hack, but when there's no other way, a dirty hack becomes an elegant solution ;).
This code compiles to the main executable:
core/module.h
template<void (*init)()>
struct Module
{
Module()
{
init();
}
};
// generates: extern void initDummy(); Module<initDummy> DummyInstance
#define MODULE_INSTANCE(name) \
extern void init ## name(); \
Module<init ## name> name ## Instance
core/action.h
struct Action // an abstract action
{
};
void addAction(Action& action); // adds the abstract action to a list
main.cpp
#include "core/module.h"
int main()
{
MODULE_INSTANCE(Dummy);
}
This code implements the Dummy module and compiles to a separate library:
dummy/action.h
#include "core/action.h"
struct DummyAction : Action // a concrete action
{
};
dummy/init.cpp
#include "action.h"
void initDummy()
{
addAction(*new DummyAction());
}
If you wanted to go further (this part is not portable) you could write a separate program to generate a list of MODULE_INSTANCE calls, one for each module in your application, and output a generated header file:
generated/init.h
#include "core/module.h"
#define MODULE_INSTANCES \
MODULE_INSTANCE(Module1); \
MODULE_INSTANCE(Module2); \
MODULE_INSTANCE(Module3);
Add this as a pre-build step, and core/main.cpp becomes:
#include "generated/init.h"
int main()
{
MODULE_INSTANCES
}
If you later decide to load some or all of these modules dynamically, you can use exactly the same pattern to dynamically load, initialise and unload a dll. Please note that the following example is windows-specific, untested and does not handle errors:
core/dynamicmodule.h
struct DynamicModule
{
HMODULE dll;
DynamicModule(const char* filename, const char* init)
{
dll = LoadLibrary(filename);
FARPROC function = GetProcAddress(dll, init);
function();
}
~DynamicModule()
{
FreeLibrary(dll);
}
};
#define DYNAMICMODULE_INSTANCE(name) \
DynamicModule name ## Instance = DynamicModule(#name ".dll", "init" #name)
As Mike Seymour stated the static template stuff will not give you the dynamic loading facilities you want. You could load your modules dynamically as plug ins. Put dlls containing an action each into the working directory of the application and load these dlls dynamically at run-time. This way you will not have to change your source code in order to use different or new implementations of CAction.
Some frameworks make it easy to load custom plug ins, for example Qt.
I know about the Strategy and Abstract Factory design patterns - however they don't solve my current problem:
I'm creating a C++ library that offers a very basic GUI. However I want the user to be able to choose at compile time which GUI library to use (say Qt or FLTK) to actually render the GUI. The user should however only need to know about the methods in my library.
It should be possible to compile the same code without any changes using either a Qt backend or an FLTK backend.
I thought of something like:
class A
{
// do things that are not specific to QT or FLTK here as there are many
// methods I will need independent of the backend
}
class QT_A : public A
{
// Implement the actual creation of a window, display of a widget here using Qt
}
class FLTK_A : public A
{
// Implement the actual creation of a window, display of a widget here using FLTK
}
The problem is that I do not want the user to know about QT_A or FLTK_A. The user (developer) should just deal with A. Also, I can't have both variants at the same time as I don't want my library to depend on both Qt and FLTK; just whichever was chosen at compile time.
One option is the Pimpl idiom described in another answer.
Another option is a factory returning a pointer to the interface class:
std::unique_ptr<A> make_A()
{
#if defined(USING_QT)
return std::unique_ptr<A>(new QT_A(...));
#elif defined(USING_FLTK)
return std::unique_ptr<A>(new FLTK_A(...));
#else
#error "No GUI library chosen"
#endif
}
The Pimpl idiom may be an alternative. It allows you to create a common interface without framework dependent members.
class A
{
struct impl;
std::unique_ptr<impl> pimpl; // or scoped_ptr/auto_ptr on non-C++11
public:
A();
~A();
void do_sth();
};
Then, the source file can provide different implementations of impl depending on the backend.
#ifdef QT
struct A::impl : QWidget { // Make it polymorphic, if you need
QImage img;
QString data;
};
void A::do_sth()
{
impl->make_it(); // full access to the Qt things
}
A::A()
: pimpl(new ...)
{
}
A::~A() {} // no need for delete thanks the smart pointer
#endif
No need of fancy patterns.
You distribute
headers of A;
a library that contains A, QT_A, and make_A function;
another library that contains A, FLTK_A and another implementation of make_A function.
The user links to either library.
I have a set of related C++ classes which must be wrapped and exported from a DLL in such a way that it can be easily consumed by C / FFI libraries. I'm looking for some "best practices" for doing this. For example, how to create and free objects, how to handle base classes, alternative solutions, etc...
Some basic guidelines I have so far is to convert methods into simple functions with an extra void* argument representing the 'this' pointer, including any destructors. Constructors can retain their original argument list, but must return a pointer representing the object. All memory should be handled via the same set of process-wide allocation and free routines, and should be hot-swappable in a sense, either via macros or otherwise.
Foreach public method you need a C function.
You also need an opaque pointer to represent your class in the C code.
It is simpler to just use a void* though you could build a struct that contains a void* and other information (For example if you wanted to support arrays?).
Fred.h
--------------------------------
#ifdef __cplusplus
class Fred
{
public:
Fred(int x,int y);
int doStuff(int p);
};
#endif
//
// C Interface.
typedef void* CFred;
//
// Need an explicit constructor and destructor.
extern "C" CFred newCFred(int x,int y);
extern "C" void delCFred(CFred);
//
// Each public method. Takes an opaque reference to the object
// that was returned from the above constructor plus the methods parameters.
extern "C" int doStuffCFred(CFred,int p);
The the implementation is trivial.
Convert the opaque pointer to a Fred and then call the method.
CFred.cpp
--------------------------------
// Functions implemented in a cpp file.
// But note that they were declared above as extern "C" this gives them
// C linkage and thus are available from a C lib.
CFred newCFred(int x,int y)
{
return reinterpret_cast<void*>(new Fred(x,y));
}
void delCFred(CFred fred)
{
delete reinterpret_cast<Fred*>(fred);
}
int doStuffCFred(CFred fred,int p)
{
return reinterpret_cast<Fred*>(fred)->doStuff(p);
}
While Loki Astari's answer is very good, his sample code puts the wrapping code inside the C++ class. I prefer to have the wrapping code in a separate file. Also I think it is better style to prefix the wrapping C functions with the class name.
The following blog posts shows how to do that:
http://blog.eikke.com/index.php/ikke/2005/11/03/using_c_classes_in_c.html
I copied the essential part because the blog is abandoned and might finally vanish (credit to Ikke's Blog):
First we need a C++ class, using one header file (Test.hh)
class Test {
public:
void testfunc();
Test(int i);
private:
int testint;
};
and one implementation file (Test.cc)
#include <iostream>
#include "Test.hh"
using namespace std;
Test::Test(int i) {
this->testint = i;
}
void Test::testfunc() {
cout << "test " << this->testint << endl;
}
This is just basic C++ code.
Then we need some glue code. This code is something in-between C and C++. Again, we got one header file (TestWrapper.h, just .h as it doesn't contain any C++ code)
typedef void CTest;
#ifdef __cplusplus
extern "C" {
#endif
CTest * test_new(int i);
void test_testfunc(const CTest *t);
void test_delete(CTest *t);
#ifdef __cplusplus
}
#endif
and the function implementations (TestWrapper.cc, .cc as it contains C++ code):
#include "TestWrapper.h"
#include "Test.hh"
extern "C" {
CTest * test_new(int i) {
Test *t = new Test(i);
return (CTest *)t;
}
void test_testfunc(const CTest *test) {
Test *t = (Test *)test;
t->testfunc();
}
void test_delete(CTest *test) {
Test *t = (Test *)test;
delete t;
}
}
First, you might not need to convert all your methods to C functions. If you can simplify the API and hide some of the C++ interface, it is better, since you minimize the chance to change the C API when you change C++ logic behind.
So think of a higher level abstraction to be provided through that API. Use that void* solution you described. It looks to me the most appropriate (or typedef void* as HANDLE :) ).
Some opinions from my experience:
functions should return codes to represent errors. It's useful to have a function returning error description in string form. All other return values should be out parameters.
E.g.:
C_ERROR BuildWidget(HUI ui, HWIDGET* pWidget);
put signatures into structures/classes your handles pointer to for checking handles on validness.
E.g. your function should look like:
C_ERROR BuildWidget(HUI ui, HWIDGET* pWidget){
Ui* ui = (Ui*)ui;
if(ui.Signature != 1234)
return BAD_HUI;
}
objects should be created and released using functions exported from DLL, since memory allocation method in DLL and consuming app can differ.
E.g.:
C_ERROR CreateUi(HUI* ui);
C_ERROR CloseUi(HUI hui); // usually error codes don't matter here, so may use void
if you are allocating memory for some buffer or other data that may be required to persist outside of your library, provide size of this buffer/data. This way users can save it to disk, DB or wherever they want without hacking into your internals to find out actual size. Otherwise you'll eventually need to provide your own file I/O api which users will use only to convert your data to byte array of known size.
E.g.:
C_ERROR CreateBitmap(HUI* ui, SIZE size, char** pBmpBuffer, int* pSize);
if your objects has some typical representation outside of your C++ library, provide a mean of converting to this representation (e.g. if you have some class Image and provide access to it via HIMG handle, provide functions to convert it to and from e.g. windows HBITMAP). This will simplify integration with existing API.
E.g.
C_ERROR BitmapToHBITMAP(HUI* ui, char* bmpBuffer, int size, HBITMAP* phBmp);
Use vector (and string::c_str) to exchange data with non C++ APIs. (Guideline #78 from C++ Coding Standards, H. Sutter/ A. Alexandrescu).
PS It's not that true that "constructors can retain their original argument list". This is only true for argument types which are C-compatible.
PS2 Of course, listen to Cătălin and keep your interface as small and simple as possible.
This may be of interest: "Mixing C and C++" at the C++ FAQ Lite. Specifically [32.8] How can I pass an object of a C++ class to/from a C function?
I want to generate C wrappers from C++ libraries.
There are tutorials on how to do it by hand:
http://dsc.sun.com/solaris/articles/mixing.html
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
But it is too much of a manual labor.
For example, for this:
struct RtAudio {
virtual DeviceInfo const& f() {...}
class DeviceInfo {
virtual void g() { ... }
};
...
};
I need to write:
struct RtAudioC {
RtAudio x;
};
struct DeviceInfo {
RtAudio::DeviceInfo x;
};
extern "C" {
RtAudioC* newRtAudio() {
return new RtAudioC;
}
void deleteRtAudio(RtAudioC *p {
delete p;
}
/* do something with RtAudio::f() */
void g(DeviceInfo *p) {
try {
p->x.g();
} catch (SomeError & err) {
}
}
}
Are there tools that can automate this process?
You can try SWIG, C code generator was last year's GSoC project. AFAIK they haven't merged it to the trunk yet, so you'd have to checkout & build the branch from SVN.
I just developed a C function wrapper in Python to do exactly this (generate C++ classes that wrap C functions).
It's still young but the bulk of what I needed it to do is in there now. Give it a try and let me know what you think: https://github.com/mlb5000/CFunctionWrapperGenerator
There is gmmproc which creates C++ wrappers for gobject based C libraries, but that's the only code generator I've heard of between C and C++.
If you're good with writing a parser, it wouldn't be too difficult a task to create a basic wrapper generator. In the end you might have to add a few finishing touches manually, but still your work load would be reduced.
How much of your C++ code is already written vs. how much has yet to be written?
If a reasonable proportion is to-be-written, I would create a simplified syntax, that generates both the C++ and C headers, like IDL does for COM interfaces. This simplified syntax will be much easier for you to parse than C++, or you can likely find something off the shelf that does this.
I don't know of an off-the-shelf tool to do this. If you want to automate the generation and are happy to write your own scripts, pygccxml (based on GCC-XML) is quite a nice way to parse C++ headers.