PaulH <paul.h...@gmail.com> wrote:
The header file looks basically like this (below). So, I just
dynamically load the library, get function pointers to the Get() and
Destroy() methods, and that's how I access the class.
#ifdef MY_EXPORTS
#define MY_API __declspec( dllexport )
#else
#define MY_API __declspec( dllimport )
#endif
#ifdef __cplusplus
extern "C" {
#endif
class MY_API CMyAPI {
public:
virtual BOOL MyFunc1() = 0;
virtual BOOL MyFunc2() = 0;
virtual BOOL MyFunc3() = 0;
virtual BOOL MyFunc4() = 0;
};
MY_API CMyAPI* CreateClass();
MY_API void DestroyClass( CMyAPI* pCtrl );
typedef CMyAPI* ( *PFN_GET_MY_CLASS )();
typedef void ( *PFN_DESTROY_MY_CLASS )( CMyAPI* );
#ifdef __cplusplus
};
#endif
My problem is that if I add a new function, MyNewFunc(), to the class
in the DLL and then try to run a program compiled with an older
version of the header file, when I try to call MyFunc2(), or
something, I may end up calling MyNewFunc() instead!
Which is precisely why COM interfaces are immutable once published. Why
don't you just use COM, rather than trying to come up with your own
COM-like arrangement?
You will likely get away with adding an extra function if you make sure
to add it at the end of the list.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
the simple thing I wanted to do.