How to wrap C library callbacks in C++/CLI - c++

Given the following C library with a callback event that ask to set a buffer, how to write a proper C++/CLI wrapper in a type safe manner?
// The callback signature
typedef void (__cdecl *BUFFERALLOCATOR)(void *opaque, void **buffer);
// A struct that contains the context of the library
struct lib_context_base_s
{
// The stored callback function pointer
BUFFERALLOCATOR buffer_allocator;
// Opaque pointer that contain the local context. Needed in C because
// C doesn't have closures (functions that knows the context where
// they are defined)
void* opaque;
};
typedef struct lib_context_base_s lib_context_base;
// Init the base context
lib_context_base* new_lib_context_base()
{
return malloc(sizeof(lib_context_base));
}
// Free the base context
void free_lib_context_base(lib_context_base *lib_context_base)
{
free(lib_context_base);
}
// Set the buffer allocation callback
void set_allocate_buffer_callback(lib_context_base *lib_context_base,
BUFFERALLOCATOR allocate_buffer, void* opaque)
{
lib_context_base->buffer_allocator = allocate_buffer;
lib_context_base->opaque = opaque;
}
The library should be usable by managed code using the delegate void BufferAllocator(ref IntPtr buffer) .

I will insist on type-safe principles: I know there's already Marshal.GetFunctionPointerForDelegate but that requires function pointer type cast in C++/CLI and hides how marshalling unmanaged->managed works (debugging is much harder and I don't like not understanding what's happening behing the scene). Just noticed the approach is similar to this but doesn't need a managed native class (less overhead). Please, tell me if you know how to further simplify it (mantaining type safety and marshaling control) and reduce overhead.
The following is the C++/CLI Wrapper.h header:
#include <gcroot.h>
using namespace System;
using namespace System::Runtime::InteropServices;
namespace LibraryWrapper
{
// Declare the cdecl function that will be used
void cdecl_allocate_buffer(void *opaque, void **buffer);
public ref class Library
{
public:
// The BufferAllocator delegate declaration, available to any clr language
// [In, Out] attributes needed (?) to pass the pointer as reference
delegate void BufferAllocator([In, Out] IntPtr% buffer);
internal:
// The stored delegate ref to be used later
BufferAllocator ^_allocate_buffer;
private:
// Native handle of the ref Library class, castable to void *
gcroot<Library^> *_native_handle;
// C library context
lib_context_base *_lib_context_base;
public:
Library();
~Library();
// The clr callback setter equivalent to the C counterpart, don't need
// the context because in CLR we have closures
void SetBufferAllocateCallback(BufferAllocator ^allocateBuffer);
};
}
Follows C++/CLi Wrapper.cpp defines:
#include "wrapper.h"
namespace LibraryWrapper
{
Library::Library()
{
// Construct the native handle
_native_handle = new gcroot<Library^>();
// Initialize the library base context
_lib_context_base = new_lib_context_base();
// Null the _allocate_buffer delegate instance
_allocate_buffer = nullptr;
}
Library::~Library()
{
free_lib_context_base(_lib_context_base);
delete _native_handle;
}
void Library::SetBufferAllocateCallback(BufferAllocator ^allocateBuffer)
{
_allocate_buffer = allocateBuffer;
// Call the C lib callback setter. Use _native_handle pointer as the opaque data
set_allocate_buffer_callback(_lib_context_base, cdecl_allocate_buffer,
_native_handle);
}
void cdecl_allocate_buffer(void *opaque, void **buffer)
{
// Cast the opaque pointer to the hnative_handle ref (for readability)
gcroot<Library^> & native_handle = *((gcroot<Library^>*)opaque);
// Prepare a IntPtr wrapper to the buffer pointer
IntPtr buffer_cli(*buffer);
// Call the _allocate_buffer delegate in the library wrapper ref
native_handle->_allocate_buffer(buffer_cli);
// Set the buffer pointer to the value obtained calling the delegate
*buffer = buffer_cli.ToPointer();
}
}
Can be used in this way (C#):
// Allocate a ~10mb buffer in unmanaged memory. Will be deallocated
// automatically when buffer go out of scope
IntPtr _buffer = Marshal.AllocHGlobal(10000000);
// Init the library wrapper
Library library = new Library();
// Set the callback wrapper with an anonymous method
library.SetBufferAllocateCallback(delegate(ref IntPtr buffer)
{
// Because we have closure, I can use the _buffer variable in the outer scope
buffer = _buffer;
});

Related

Call a managed class member function from an unmanaged class member [duplicate]

How do I pass a function pointer from managed C++ (C++/CLI) to an unmanaged method? I read a few articles, like this one from MSDN, but it describes two different assemblies, while I want only one.
Here is my code:
1) Header (MyInterop.ManagedCppLib.h):
#pragma once
using namespace System;
namespace MyInterop { namespace ManagedCppLib {
public ref class MyManagedClass
{
public:
void DoSomething();
};
}}
2) CPP Code (MyInterop.ManagedCppLib.cpp)
#include "stdafx.h"
#include "MyInterop.ManagedCppLib.h"
#pragma unmanaged
void UnmanagedMethod(int a, int b, void (*sum)(const int))
{
int result = a + b;
sum(result);
}
#pragma managed
void MyInterop::ManagedCppLib::MyManagedClass::DoSomething()
{
System::Console::WriteLine("hello from managed C++");
UnmanagedMethod(3, 7, /* ANY IDEA??? */);
}
I tried creating my managed delegate and then I tried to use Marshal::GetFunctionPointerForDelegate method, but I couldn't compile.
Yes, you want Marshal::GetFunctionPointerForDelegate(). Your code snippet is missing the managed function you'd want to call, I just made one up. You will also have to declare the managed delegate type and create an instance of it before you can get a function pointer. This worked well:
#include "stdafx.h"
using namespace System;
using namespace System::Runtime::InteropServices;
#pragma managed(push, off)
typedef void (* UnmanagedSummer)(int arg);
void UnmanagedMethod(int a, int b, UnmanagedSummer sum)
{
int result = a + b;
sum(result);
}
#pragma managed(pop)
ref class Test {
delegate void ManagedSummer(int arg);
public:
static void Run() {
Test^ t = gcnew Test();
ManagedSummer^ managed = gcnew ManagedSummer(t, &Sum);
IntPtr stubPointer = Marshal::GetFunctionPointerForDelegate(managed);
UnmanagedSummer functionPointer = static_cast<UnmanagedSummer>(stubPointer.ToPointer());
UnmanagedMethod(1, 2, functionPointer);
GC::KeepAlive(managed); // Important: ensure stub can't be collected while native code is running
System::Diagnostics::Debug::Assert(t->summed == 3);
}
void Sum(int arg) {
summed += arg;
}
int summed;
};
int main(array<System::String ^> ^args)
{
Test::Run();
return 0;
}
Here's another way to do it based on my experiences implementing a .NET wrapper in C++/CLI around the CartoType C++ map rendering library. This is tested and working code.
The C++ API has an asynchronous Find function which takes a callback:
TResult CartoType::CFramework::FindAsync(FindAsyncCallBack aCallBack,const TFindParam& aFindParam,bool aOverride = false);
The callback is a function of this type:
using FindAsyncCallBack = std::function<void(std::unique_ptr<CMapObjectArray> aMapObjectArray)>;
The task is to provide a .NET wrapper for this function by adding C++/CLI code to the existing wrapper system. First I define a suitable delegate type for my .NET function (an equivalent to FindAsyncCallback in the C++ API):
public delegate void FindAsyncDelegate(MapObjectList^ aMapObjectList);
The signature of the .NET function is thus:
Result FindAsync(FindAsyncDelegate^ aDelegate,FindParam^ aFindParam,bool aOverride);
The main implementation problem to be solved is how to call the native C++ function and provide a native callback function which can then call the delegate passed in by the caller of the .NET function. An associated task is to keep the delegate and the native callback function object alive until the asynchronous function's thread has done its job. Here's how it's done.
I define a C++/CLI delegate type that's the same as the C++ callback function type, and a class to hold the delegate passed in by the caller to the .NET function (of type FindAsyncDelegate), and a delegate of the type to be passed to C++ (of type NativeAsyncHandler):
delegate void NativeAsyncHandler(std::unique_ptr<CMapObjectArray> aMapObjectArray);
ref class FindAsyncHelper
{
public:
FindAsyncHelper(Framework^ aFramework,FindAsyncDelegate^ aDelegate):
m_framework(aFramework),
m_delegate(aDelegate)
{
}
void Handler(std::unique_ptr<CMapObjectArray> aMapObjectArray)
{
MapObjectList^ o = gcnew MapObjectList;
SetMapObjectList(m_framework,o,*aMapObjectArray);
m_delegate(o);
// Remove this object from the list held by the framework so that it can be deleted.
m_framework->m_find_async_helper_list->Remove(this);
}
Framework^ m_framework;
FindAsyncDelegate^ m_delegate;
NativeAsyncHandler^ m_native_handler;
};
The idea is that we create a FindAsyncHelper object with the two delegates in it, then call the native FindAsync function with the native delegate, arranged to call Handler(), which then calls the original caller's delegate.
And here is how it's implemented:
typedef void(*FIND_ASYNC_CALLBACK)(std::unique_ptr<CMapObjectArray> aMapObjectArray);
Result Framework::FindAsync(FindAsyncDelegate^ aDelegate,FindParam^ aFindParam,bool aOverride)
{
if (aDelegate == nullptr || aFindParam == nullptr)
return Result::ErrorInvalidArgument;
TFindParam param;
SetFindParam(param,aFindParam);
FindAsyncHelper^ h = gcnew FindAsyncHelper(this,aDelegate);
h->m_native_handler = gcnew NativeAsyncHandler(h,&FindAsyncHelper::Handler);
IntPtr p = Marshal::GetFunctionPointerForDelegate(h->m_native_handler);
FIND_ASYNC_CALLBACK f = static_cast<FIND_ASYNC_CALLBACK>(p.ToPointer());
TResult error = m_framework->FindAsync(f,param,aOverride);
// Keep h alive by adding it to a list.
m_find_async_helper_list->Add(h);
return (Result)(int)error;
}
Some notes:
The statements
FindAsyncHelper^ h = gcnew FindAsyncHelper(this,aDelegate);
h->m_native_handler = gcnew NativeAsyncHandler(h,&FindAsyncHelper::Handler);
create a FindAsyncHandler object and store a native handler object in it; keeping it here means we only have one object to keep alive, the FindAsyncHandler. The next statements:
IntPtr p = Marshal::GetFunctionPointerForDelegate(h->m_native_handler);
FIND_ASYNC_CALLBACK f = static_cast<FIND_ASYNC_CALLBACK>(p.ToPointer());
get a function pointer that can be passed to native code, and cast it to the right function pointer type. We can't cast it directly to the std::function type used in FindAsyncCallback, so the cumbersome extra typedef is necessary.
At last the native FindAsync function can be called:
TResult error = m_framework->FindAsync(f,param,aOverride);
And then, to make sure the various callback functions stay alive, the FindAsyncHandler is added to a list owned by the main framework object:
m_find_async_helper_list->Add(h);
It is taken off the list when the task is completed and FindAsyncHelper::Handler is called.

Detecting and clearing wrong object imported from dll in C++

I have a dll ("so.dll") definition as follow, in which I have a function TestWrongClass, which returns a pointer
to a class object (TestWrongClass).
/////// "IOReader.h" //////////////
class IOReader
{
public :
IOReader() {};
virtual ~IOReader() {};
virtual bool open(const std::string &format,
const std::string &fileName, const int mask) = 0;
std::string errorMessage;
};
// "IOReader.h" Ends Here
// ---- so.dll ---- /
//////////////// sio.h ////////////
#ifdef SEIO_EXPORTS
#define SEIO_API __declspec(dllexport)
#else
#define SEIO_API __declspec(dllimport)
#endif
#include <string>
#include "IOReader.h"
class SReaderIO : public IOReader
{
public:
SReaderIO() {};
bool open(const std::string &format,
const std::string &fileName, const int mask)
{
return true;
}
};
class TestWrongClass
{
public:
TestWrongClass() { };
bool open(const std::string &format,
const std::string &fileName, const int mask)
{
return true;
}
};
SEIO_API TestWrongClass* CreateIOReader()
{
TestWrongClass * module = new TestWrongClass();
return module;
}
//// sio.h ends here ///////
//in the main executable I am loading the dll on run time
// and after creating a object of type TestWrongClass,
//I explicitly try to cast it with the wrong object, as follows
/// Main Source //
#include <iostream>
#include <windows.h>
#include "IOReader.h"
int main ()
{
HMODULE hDLL=LoadLibrary(L"sIO.dll");
CreateSealafineReaderFn _funcSelafinCreator = NULL;
_funcSelafinCreator = (CreateSealafineReaderFn) GetProcAddress (hDLL,
"CreateIOReader");
// Method 1
void *Iref = (_funcSelafinCreator)();
IOReader * locReader = NULL;
locReader = reinterpret_cast <IOReader *>(Iref); // but how to check
// that object locReader is not of base type IOReader
// so that I may call delete Iref
// If I try to do as follow, then I get illegal error from compiler
// locReader = dynamic_cast <IOReader *>(Iref); // illegal
// Method 2
try
{
locReader = dynamic_cast <IOReader *>((_funcSelafinCreator)());
// works but how can I check wrong casting and catch exception
} catch (std::bast_cast)
{
// how to clear the object created by CreateIOReader
}
}
//
The reason why I doing this process is to check if any dlls, which the main program will be scanning from the dll directory
may be having a method of the same name, however return pointer type of the created object by the method may be different, which is not desired.
(In the above mentioned case the method is CreateIOReader)
if I use dynamic_cast, I can check for the bad_cast exception, however the object will be already created in the dll, and won't be freed, since I
don't have access to the internal code of the dll.
the above method which I have given using reintepret_cast works, however I cannot check whether the correct object type is returned or not.
if get to know by some method that if the casting is not of correct type, then I can call delete on the Iref pointer "delete Iref" to clear the object from the heap.
Is there any method to check creation of wrong object by the method CreateIOReader, and thus delete it from the executable source code
For this problem dynamic_cast cannot help you. The issue is that you do not know the real return type of your function, and are just pretending it is IOReader*, when it could in fact be something else (i.e. TestWrongClass*). Under aliasing rules this is not allowed.
Contrast this with the situation:
class IBase { ... };
class IOReader : public IBase { ... };
class TestWrongClass : public IBase { ... };
where you also know that your function returns an IBase*. Here indeed a dynamic cast could help you, as IOReader and TestWrongClass have common ancestry, and it would be valid to refer to either through a IBase*.
I have to say it is a strange problem to have: a call to a library function where you have no idea what might be returned. I would suggest changing the design somewhat. You could (amongst other things):
Create the unified hierarchy as per above
Have the call return something like std::pair<int, void*>, where the int (or enum) would be a reliable way to determine what is being returned, after which you could reinterpret_cast the void*
If you choose approach 1, then to address your deletion problem, you could add a function like destroy() to the IBase interface, which would cause the library to delete the object (note: it is bad idea to delete yourself objects that are given to you by an external library).
If you choose approach 2, then perhaps you could have a library function like void destroy(int, void*), to which you could pass the members of your std::pair in case you received something other than what you wanted. The library could then use these to cast the void* back into the right thing to delete it internally.

Is this usage of gcroot safe?

I need to use an unmanaged API from C++/CLI. This API stores a void pointer to arbitrary user data and a few callbacks. It then eventually calls those callbacks, passing the user data in as void*.
So far I had a native class passing its "this" pointer as the user data, and using that pointer to have the API call back into this class, i.e.:
static void __stdcall Callback(void* userData) {
((MyType*)userData)->Method();
}
class MyType {
public:
MyType() { RegisterWithApi((void*)this, Callback); }
void Method();
};
I'm trying to translate this using a managed class. I found that the type gcroot can be used to safely store a managed reference in native code, so here's how I'm doing it now:
// This is called by the native API
static void __stdcall Callback(void* userData) {
// Cast back to gcroot and call into managed code
(*(gcroot<MyType^>*)userData)->Method();
}
ref class MyType {
gcroot<MyType^>* m_self;
public:
MyType() {
m_self = new gcroot<MyType^>;
RegisterWithApi((void*)m_self, Callback);
}
~MyType() { delete m_self; }
// Method we want called by the native API
void Method();
}
While this seems fine to the C++/CLI compiler, I am not perfectly re-assured. From what I understand, gcroot somehow keeps track of its managed reference as it is moved by the GC. Will it manage to do this while stored as a void* by unmanaged code? Is this code safe?
Thanks.
This is what I ended up doing and it works perfectly. The purpose of gcroot is to store a managed reference on the native heap, which is precisely what I'm doing here.
No! It's exactly the other way around. gcroot is a native class template. You use it to store a handle to managed memory in a native type which is compiled with clr support. You will typically use it to divert calls to member functions of a native object to a managed object stored in a member of type gcroot.
EDIT: I was on mobile yesterday where typing code examples is a bit awkward... The intended and typical usage of gcroot<T^> is somewhere along these lines:
// ICallback.h
struct ICallback {
virtual void Invoke() = 0;
virtual void Release() = 0;
protected:
~ICallback() {}
};
That is what your native apps or libraries see and include. Then, you have a mixed component compiled with CLR support, which implements ICallback and stores a handle to some managed object in a gcroot<ManagedType^>:
// Callback.cpp (this translation unit must be compiled with /clr)
// I did not compile and test, but you get the point...
template<class T^> class Callback : public ICallback {
gcroot<T^> m_Managed;
virtual void Invoke()
{
m_Managed->Invoke();
}
virtual void Release()
{
delete this;
}
public:
Callback(T^ p_Managed) : m_Managed(p_Managed) {}
};
__declspec( dllexport ) ICallback* CreateCallback()
{
auto t_Managed = gcnew SomeManagedType();
return new Callback<System::Action^>(
gcnew System::Action(t_Managed, &SomeManagedType::Method));
}
Your native apps call CreateCallback, recieve an instance of ICallback which when Invoke-d calls a method of managed type, held in gcroot<System::Action^>...

How to pass a Function pointer without exposing class details

I'm creating a library that needs to allow the user to set a callback function.
The interface of this library is as below:
// Viewer Class Interface Exposed to user
/////////////////////////////
#include "dataType_1.h"
#include "dataType_2.h"
class Viewer
{
void SetCallbackFuntion( dataType_1* (Func) (dataType_2* ) );
private:
dataType_1* (*CallbackFunction) (dataType_2* );
}
In a typical usage, the user needs to access an object of dataType_3 within the callback.
However, this object is only known only to his program, like below.
// User usage
#include "Viewer.h"
#include "dataType_3.h"
// Global Declaration needed
dataType_3* objectDataType3;
dataType_1* aFunction( dataType_2* a)
{
// An operation on object of type dataType_3
objectDataType3->DoSomething();
}
main()
{
Viewer* myViewer;
myViewer->SetCallbackFunction( &aFunction );
}
My Question is as follows:
How do I avoid using an ugly global variable for objectDataType3 ?
(objectDataType3 is part of libraryFoo and all the other objects dataType_1, dataType_2 & Viewer are part of libraryFooBar) Hence I would like them to remain as separate as possible.
Don't use C in C++.
Use an interface to represent the fact you want a notification.
If you want objects of type dataType_3 to be notified of an event that happens in the viewer then just make this type implement the interface then you can register the object directly with the viewer for notification.
// The interface
// Very close to your function pointer definition.
class Listener
{
public: virtual dataType_1* notify(dataType_2* param) = 0;
};
// Updated viewer to use the interface defineition rather than a pointer.
// Note: In the old days of C when you registered a callback you normally
// also registered some data that was passed to the callback
// (see pthread_create for example)
class Viewer
{
// Set (or Add) a listener.
void SetNotifier(Listener* l) { listener = l; }
// Now you can just inform all objects that are listening
// directly via the interface. (remember to check for NULL listener)
void NotifyList(dataType_2* data) { if (listener) { listener->notify(data); }
private:
Listener* listener;
};
int main()
{
dataType_3 objectDataType3; // must implement the Listener interface
Viewer viewer;
viewer.SetNotifier(&objectDataType3);
}
Use Boost.Function:
class Viewer
{
void SetCallbackFuntion(boost::function<datatype_1* (dataType_2*)> func);
private:
boost::function<datatype_1* (dataType_2*)> CallbackFunction;
}
Then use Boost.Bind to pass the member function pointer together with your object as the function.
If you don't want or can't use boost, the typical pattern around callback functions like this is that you can pass a "user data" value (mostly declared as void*) when registering the callback. This value is then passed to the callback function.
The usage then looks like this:
dataType_1* aFunction( dataType_2* a, void* user_ptr )
{
// Cast user_ptr to datatype_3
// We know it works because we passed it during set callback
datatype_3* objectDataType3 = reinterpret_cast<datatype_3*>(user_ptr);
// An operation on object of type dataType_3
objectDataType3->DoSomething();
}
main()
{
Viewer* myViewer;
dataType_3 objectDataType3; // No longer needs to be global
myViewer->SetCallbackFunction( &aFunction, &objectDataType3 );
}
The implementation on the other side only requires to save the void* along with the function pointer:
class Viewer
{
void SetCallbackFuntion( dataType_1* (Func) (dataType_2*, void*), void* user_ptr );
private:
dataType_1* (*CallbackFunction) (dataType_2*, void*);
void* user_ptr;
}
boost::/std:: function is the solution here. You can bind member functions to them, and in addition functors and lambdas, if you have a lambda compiler.
struct local {
datatype3* object;
local(datatype3* ptr)
: object(ptr) {}
void operator()() {
object->func();
}
};
boost::function<void()> func;
func = local(object);
func(); // calls object->func() by magic.
Something like this is simple to do:
class Callback
{
public:
virtual operator()()=0;
};
template<class T>
class ClassCallback
{
T* _classPtr;
typedef void(T::*fncb)();
fncb _cbProc;
public:
ClassCallback(T* classPtr,fncb cbProc):_classPtr(classPtr),_cbProc(cbProc){}
virtual operator()(){
_classPtr->*_cbProc();
}
};
Your Viewer class would take a callback, and call it using the easy syntax:
class Viewer
{
void SetCallbackFuntion( Callback* );
void OnCallCallback(){
m_cb->operator()();
}
}
Some other class would register the callback with the viewer by using the ClassCallback template specialization:
// User usage
#include "Viewer.h"
#include "dataType_3.h"
main()
{
Viewer* myViewer;
dataType_3 objectDataType3;
myViewer->SetCallbackFunction( new ClassCallback<dataType_3>(&objectDataType3,&dataType_3::DoSomething));
}
You're asking several questions mixed up in here and this is going to cause you lots of confusion in your answers.
I'm going to focus on your issue with dataType_3.
You state:
I would like to avoid declaring or
including dataType_3 in my library as
it has huge dependencies.
What you need to do is make an interface class for dataType_3 that gives the operations -- the footprint -- of dataType_3 without defining everything in it. You'll find tips on how to do that in this article (among other places). This will allow you to comfortably include a header that gives the footprint for dataType_3 without bringing in all of its dependencies. (If you've got dependencies in the public API you may have to reuse that trick for all of those as well. This can get tedious, but this is the price of having a poorly-designed API.)
Once you've got that, instead of passing in a function for callback consider having your "callback" instead be a class implementing a known interface. There are several advantages to doing this which you can find in the literature, but for your specific example there's a further advantage. You can inherit that interface complete with an instantiated dataType_3 object in the base class. This means that you only have to #include the dataType_3 interface specification and then use the dataType_3 instance provided for you by the "callback" framework.
If you have the option of forcing some form of constraints on Viewer, I would simply template that, i.e.
template <typename CallBackType>
class Viewer
{
public:
void SetCallbackFunctor(CallBackType& callback) { _callee = callback; }
void OnCallback()
{
if (_callee) (*_callee)(...);
}
private:
// I like references, but you can use pointers
boost::optional<CallBackType&> _callee;
};
Then in your dataType_3 implement the operator() to do as needed, to use.
int main(void)
{
dataType_3 objectDataType3;
// IMHO, I would construct with the objectDataType3, rather than separate method
// if you did that, you can hold a direct reference rather than pointer or boost::optional!
Viewer<dataType_3> viewer;
viewer.SetCallbackFunctor(objectDataType3);
}
No need for other interfaces, void* etc.

C++: static function wrapper that routes to member function?

I've tried all sorts of design approaches to solve this problem, but I just can't seem to get it right.
I need to expose some static functions to use as callback function to a C lib. However, I want the actual implementation to be non-static, so I can use virtual functions and reuse code in a base class. Such as:
class Callbacks {
static void MyCallBack() { impl->MyCallBackImpl(); }
...
class CallbackImplBase {
virtual void MyCallBackImpl() = 0;
However I try to solve this (Singleton, composition by letting Callbacks be contained in the implementor class, etc) I end up in a dead-end (impl usually ends up pointing to the base class, not the derived one).
I wonder if it is at all possible or if I'm stuck with creating some sort of helper functions instead of using inheritance?
Problem 1:
Though it may look and seem to work on your setup this is not guaranteed to work as the C++ ABI is not defined. So technically you can not use C++ static member functions as functions pointers to be used by C code.
Problem 2:
All C callacks (that I know of) allow you to pass user data back as a void*. You can use this as the pointer to your object that has the virtual method. BUT You must make sure you use dynamic_cast<>() to the base class (the one with the virtual method used in the callback) before it is converted into the void* otherwise the pointer at the other end may not be interpreted correctly (especially if there is multiple inheritance involved).
Problem 3:
Exceptions: C is not designed to work with exceptions (especially old C libraries with callbacks). So don't expect exceptions that escape your callback to provide anything meaningful to the caller (they are more likely to result in application termination).
Solution:
What you need to do is use extern "C" function as the callback that calls the virtual method on an object of know type and throws away all exceptions.
An example for the C pthread routines
#include <iostream>
extern "C" void* start_thread(void* data);
class Work
{
public:
virtual ~Work() {}
virtual void doWork() = 0;
};
/*
* To be used as a callback for C code this MUST be declared as
* with extern "C" linkage to make sure the calling code can
* correctly call it
*/
void* start_thread(void* data)
{
/*
* Use reinterpret_cast<>() because the only thing you know
* that you can do is cast back to a Work* pointer.
*
*/
Work* work = reinterpret_cast<Work*>(data);
try
{
work->doWork();
}
catch(...)
{
// Never let an exception escape a callback.
// As you are being called back from C code this would probably result
// in program termination as the C ABI does not know how to cope with
// exceptions and thus would not be able to unwind the call stack.
//
// An exception is if the C code had been built with a C++ compiler
// But if like pthread this is an existing C lib you are unlikely to get
// the results you expect.
}
return NULL;
}
class PrintWork: public Work
{
public:
virtual void doWork()
{
std::cout << "Hi \n";
}
};
int main()
{
pthread_t thread;
PrintWork printer;
/*
* Use dynamic_cast<>() here because you must make sure that
* the underlying routine receives a Work* pointer
*
* As it is working with a void* there is no way for the compiler
* to do this intrinsically so you must do it manually at this end
*/
int check = pthread_create(&thread,NULL,start_thread,dynamic_cast<Work*>(&printer));
if (check == 0)
{
void* result;
pthread_join(thread,&result);
}
}
It's possible. Perhaps there's a problem on how you're initializing the concrete implementation?
In fact, I remember one library that does something very similar to this. You might find it usefull to take a look at libxml++ source code. It's built on top of libxml, which is a C library.
libxml++ uses a struct of static functions to handle the callbacks. For customization, the design allows the user to provide (through virtual functions) his/her own implementations to which the callbacks are then forwarded. I guess this is pretty much your situation.
Something like the below. The singleton is in class Callback, the Instance member will return a statically allocated reference to a CallbackImpl class. This is a singleton because the reference will only be initialised once when the function is first called. Also, it must be a reference or a pointer otherwise the virtual function will not work.
class CallbackImplBase
{
public:
virtual void MyCallBackImpl() = 0;
};
class CallbackImpl : public CallbackImplBase
{
public:
void MyCallBackImpl()
{
std::cout << "MyCallBackImpl" << std::endl;
}
};
class Callback
{
public:
static CallbackImplBase & Instance()
{
static CallbackImpl instance;
return instance;
}
static void MyCallBack()
{
Instance().MyCallBackImpl();
}
};
extern "C" void MyCallBack()
{
Callback::MyCallBack();
}
Are any of the parameters passed to the callback function user defined? Is there any way you can attach a user defined value to data passed to these callbacks? I remember when I implemented a wrapper library for Win32 windows I used SetWindowLong() to attach a this pointer to the window handle which could be later retrieved in the callback function. Basically, you need to pack the this pointer somewhere so that you can retrieve it when the callback gets fired.
struct CALLBACKDATA
{
int field0;
int field1;
int field2;
};
struct MYCALLBACKDATA : public CALLBACKDATA
{
Callback* ptr;
};
registerCallback( Callback::StaticCallbackFunc, &myCallbackData, ... );
void Callback::StaticCallbackFunc( CALLBACKDATA* pData )
{
MYCALLBACKDATA* pMyData = (MYCALLBACKDATA*)pData;
Callback* pCallback = pMyData->ptr;
pCallback->virtualFunctionCall();
}