Neither (1) nor (2) should pose a problem as long as you "only ever store
an X* in an X_Handle and vice versa". For example, if Y were derived from
X, you would convert a Y* to X* before converting to X_Handle. Using
X_Handle per my previous message is really just a way to get some type
safety on the C side of the equation, for which it's much better than using
void*. Under the hood, however, it's not very different. (Windows uses a
similar technique for HWND, HFONT, etc.)

Hard to say. If the C API is as integral to your usage as the C++ API, I'd
go with the one DLL. If you go with two DLLs, your DLL clients will be able
to use either interface, which may or may not be good. Well, I guess you
could choose not to supply a C++ header, which would make things more
difficult for the would-be C++ user.

Again, as long as you keep your types consistent across the language
boundaries, "virtual" won't be a problem. As your callback takes a regular
function pointer (not a pointer to member function), you could use
something like this:

extern "C" void RegisterCallback(X_Handle obj, CB_FUNC cb, void* data)
{
  // But don't propagate exceptions...
  ((X*) obj)->registerCallback(cb, data);
}

It would get more complicated if CB_FUNC's parameters were C++ types. I'd
consider hanging it up if CB_FUNC were a pointer to member.

You might get something close to virtual functions:

// With apologies to Doug, for borrowing his code
class X
{
public:
  X();

  virtual void f();
};

class Y : public X
{
public:
 Y();

 virtual void f();
};

// C interface

#ifdef __cplusplus
extern "C" {
#endif

// Type-safe, opaque pointer.
typedef struct C_X_* X_Handle;
typedef struct C_Y_* Y_Handle;

// Export these using __declspec, for example

X_Handle CreateX();
void DestroyX(X_Handle x);

Y_Handle CreateY();
void DestroyY(Y_Handle y);

void X_f(X_Handle x);
void Y_f(Y_Handle y);

#ifdef __cplusplus
}
#endif

// C++ implementation

X_Handle CreateX()
{
  return reinterpret_cast<X_Handle>(new X);
}

void DestroyX(X_Handle x)
{
  delete reinterpret_cast<X*>(x);
}

void X_f(X_Handle x)
{
  reinterpret_cast<X*>(x)->f();
}

Y_Handle CreateY()
{
  return reinterpret_cast<Y_Handle>(new Y);
}

void DestroyY(Y_Handle y)
{
  delete reinterpret_cast<Y*>(y);
}

void Y_f(Y_Handle y)
{
  reinterpret_cast<Y*>(y)->f();
}

So far, so good. If we have an X object, we can use the CreateX, DestroyX
and X_f functions; and if we have a Y object, we can use the CreateY,
DestroyY and Y_f functions. But to truly get the "virtual" part going, we
would need to do something like this and have it work:

Y_Handle y = CreateY();
X_f(y); // if this is really virtual, it will call the Y object's version of
f.

But here's the problem: The first parameter of X_f must be of type X_Handle
(really type C_X_*). But the variable y is of type Y_Handle (or type C_Y_*).
Therefore, the code X_f(y) won't compile, because the types don't match, and
there is no implicit conversion from C_Y_* to C_X_*.

Something like X_f(reinterpret_cast<X_Handle>(y)) might do it, though. I'd
give it a shot. Presumably the y variable, which has type C_Y_* would first
be cast to type X_Handle (or C_X_*), then cast again to type X* inside the
X_f function. Then the program would see a pointer to an X object try to
select its member f function. Since y really points to a Y object, and f is
virtual, you would theoretically get Y's version of f.

Even if it doesn't work, you'll learn something about just how far you can
cast a pointer before it breaks. :)

Sean

Yes, but you'll have to be careful in some circumstances.  One thing you
might consider is exposing a COM interface, which can be consumed from C as
well as C++ and provides in essense a mapping of C++ virtual function
dispatching to C.

Derivation doesn't matter.  What matters is how you cast the 'this' pointer.
As long as there's no multiple inheritance involved, you don't really have
to worry about it.

Whichever is more appropriate to your project.  I've used both techniques,
depending on circumstances either might be better for you.  If you don't
have a good reason to implement two DLLs, I'd for for the single DLL
solution just because it's simpler.

Callbacks of this type aren't really anything special, since the callback is
an ordinary function pointer.

you'd export the callback registration function using something along the
lines of:

registerCallback(X_Handle, CB_FUNC, void*);

HTH

-cd

No, you shouldn't try to mimic the C++ type in C. The idea is for the C
side of things to work only with the opaque pointer type X_Handle, which is
declared like this:

typedef struct C_X_* X_Handle;

The struct C_X_ is an incomplete type that is never completed. You can
declare such a type inline in the typedef, like I did, and it's equivalent
to:

struct C_X_;
typedef struct C_X_* X_Handle;

You can't even dereference an X_Handle; about all you can do is copy it,
such as when you pass it to functions, and take its address. Think of
X_Handle as analogous to HWND, HDC, etc, and you've got it. The typedef
X_Handle is safer than using void*, since each C++ type exposed to C in
this way will have its own personal handle type. The name C_X_ is
arbitrary; Windows does this so much, MS created a macro to ease the
declaration of handles, and IIRC, it's called DECLARE_HANDLE.