C++/VB - Exporting Classes from DLLs

Asked By Mike

02-Aug-07 03:08 PM

A couple of weeks ago in this newsgroup (or it may have been the un-managed
version of this group), someone was asking whether they should export a
create/destroy an instance of a C++ class defined by the DLL.  I'm interested
in understanding how I can use this technique.  I have the following sample...

DLL Pseudocode...
export long createMyObject(void ** ppObjInst);
export long destroyMyObject(void ** ppObjInst);

class MyObject   //NB: No export declaration
{
/* blah blah */
};

A simple tester of this code, allows me to create and destroy an instance of
MyObject.  However, if I try to access a member function of MyObject the
linker balks with 2019 error.

It seems like my only choice is to export the class and all will be well as
I've experimented with however I'm curious to know if I'm missing another
possibility.  Ideally, I would like to do a dumpbin on the binary and see a
clean list of create/destroy functions.

Is there a way to inject the C++ class definitions into the library without
polluting the export list?

Thanks,
Mike

02-Aug-07 06:03 PM

This is unmanaged version.


Besides exporting a class you can make common abstract base
class and implement it inside DLL. Like this:

// Common header file (used both by DLL and EXE)
//
class ISomething
{
public:
...
virtual ~ISomething() {};
virtual int Foo(int param) = 0;
virtual void Delete() = 0;
};

// Export only one function:
//
__declspec(export/import) ISomething* CreateIt(...);

//// End of common header


// DLL implementation (.CPP file)
//

class CSomething : public ISomething
{
public:
...
virtual int Foo(int param) { ... }
virtual void Delete() { delete this; }
};

ISomething* CreateIt(...)
{
...
return new CSomething();
}

In EXE you call `CreateIt' to get pointer to `ISomething'
interface and use it:

ISomething* pSmth = CreateIt();
int a = pSmth->Foo(42);
...
pSmth->Delete();
pSmth = NULL;


You could get away making `CreateIt' returning `void*',
however, it's not type safe and error prone.

Alex

02-Aug-07 11:14 PM

You could always add...

__declspec(export/import) CallFoo( ISomething* );
etc...

for every function you wish to call on the Object? But it is better to
expose the class....

03-Aug-07 04:08 AM

Of course you can do it. But it is the opposite of what Mike
wants. If I understand correctly, his goal is to use a
class, which is implemented inside DLL without making new
exports (either whole class or many C functions).

Alex

03-Aug-07 09:18 AM

Thanks Alex, you are right...I'm not interested in exporting the entire class
or individual members of a class.

I tested out your earlier suggestion...thanks...that's what I was looking for.

Cheers,
Mike

03-Aug-07 05:21 PM

Using dllexport on C++ class or its members is a recipe for trouble.  Making
the call through the v-table is the correct thing to do.

03-Aug-07 06:25 PM

Just curious, why not travel the path to its logical end and make
it a COM DLL?

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

04-Aug-07 05:20 AM

See comments inline.


Actually, you don't need `DestroyObject', since an object
can destroy itself with member function.

[...]

Use of two sequential underscore characters ( __ ) at the
beginning of an identifier, or a single leading underscore
followed by a capital letter, is reserved for C++
implementations in all scopes. It is best to avoid using
such names.


`GetProcAddress' accepts LPCSTR (i.e., ANSI string) as
second parameter.


Non standard names again.


I like this approach because a class is more self-contained
this way.

Alex

05-Aug-07 01:38 AM

I knew I would get this comment. Actually I use "m_" in the projects I
develop code for money. It's my personnel projects that I have this habit of
using "__" instead of "m_" (a typing ease, I guess).