exporting a C++ object in a DLL

[Grey Alien]

I have a class that contains a std::map variable. I need to export the
class via a DLL. the class looks something like this:

class MyClass
{
public:
MyClass();
MyClass(const MyClass&);

private:
MyClass& operator=(const MyClass&);

typedef std::map<SomeKe y, SomethingElseTr easureChest ;

TreasureChest m_treasures;
};

[QbProg]

you can either __declspec(dlle xport) every member of the class that
you want to export, or __declspec(dlle xport) the class definition.

In the "dll user" code you should declare the class with
__declspec(dlli mport). There are standard ways to do that using
macros. See
http://www.codeproject.com/dll/SimpleDll2.asp

or
http://msdn2.microsoft.com/en-US/lib...4d(VS.80).aspx

Good Bye
QbProg

[Grey Alien]

QbProg wrote:

you can either __declspec(dlle xport) every member of the class that
you want to export, or __declspec(dlle xport) the class definition.

In the "dll user" code you should declare the class with
__declspec(dlli mport). There are standard ways to do that using
macros. See
http://www.codeproject.com/dll/SimpleDll2.asp

or
http://msdn2.microsoft.com/en-US/lib...4d(VS.80).aspx

Good Bye
QbProg

See: http://support.microsoft.com/kb/168958

Relevant text: The only STL container that can currently be exported is
vector. The other containers (that is, map, set, queue, list, deque) all
contain nested classes and cannot be exported.

The article was last reviewed in September 2005 - I wanted to know if it
is now possible to export std::map from a DLL

[Ben Voigt [C++ MVP]]

"Grey Alien" <gr**@andromeda .comwrote in message
news:uY******** *************@b t.com...

>I have a class that contains a std::map variable. I need to export the
class via a DLL. the class looks something like this:

No you don't. Create an interface (class with pure virtual pointers),
derive the implementation from it, and share only the interface. You do
that by putting the interface definition in a public header file. No
__declspec(dlle xport) statement is needed.

Exporting C++ classes is very bad news. __declspec(dlle xport) should be
used only for 'extern "C"' functions.

>
class MyClass
{
public:
MyClass();
MyClass(const MyClass&);

private:
MyClass& operator=(const MyClass&);

typedef std::map<SomeKe y, SomethingElseTr easureChest ;

TreasureChest m_treasures;
};

[Grey Alien]

Ben Voigt [C++ MVP] wrote:

"Grey Alien" <gr**@andromeda .comwrote in message
news:uY******** *************@b t.com...

>>I have a class that contains a std::map variable. I need to export the
class via a DLL. the class looks something like this:

No you don't.

Yes I do. I know what I want.

Create an interface (class with pure virtual pointers),

derive the implementation from it, and share only the interface. You do
that by putting the interface definition in a public header file. No
__declspec(dlle xport) statement is needed.

You are assuming that the DLL will be consumed by a C++ client. That is
not the case. Besides, how can you possibly use code in another
compilation unit if you don't link into it (either statically or
dynamically).?

>
Exporting C++ classes is very bad news. __declspec(dlle xport) should be
used only for 'extern "C"' functions.

Not necessarily true. In my case, I am taking care of the C++ "name
mangling" - through various policies and procedures (didn't include info
because it is orthogonal to my original question).

>

>>class MyClass
{
public:
MyClass();
MyClass(const MyClass&);

private:
MyClass& operator=(const MyClass&);

typedef std::map<SomeKe y, SomethingElseTr easureChest ;

TreasureChest m_treasures;
};

[David Wilkinson]

Grey Alien wrote:

You are assuming that the DLL will be consumed by a C++ client. That is
not the case. Besides, how can you possibly use code in another
compilation unit if you don't link into it (either statically or
dynamically).?

Grey:

You want to export a class containing an std::map and it will not be
consumed by a C++ client?

Ben's advice might have seemed a little fierce, but basically I agree
with it. You will save yourself a lot of future headaches if you design
your class with a pure virtual interface (and methods using simple types).

--
David Wilkinson
Visual C++ MVP

[Grey Alien]

David Wilkinson wrote:

Grey Alien wrote:

>You are assuming that the DLL will be consumed by a C++ client. That
is not the case. Besides, how can you possibly use code in another
compilation unit if you don't link into it (either statically or
dynamically) .?

Grey:

You want to export a class containing an std::map and it will not be
consumed by a C++ client?

Ben's advice might have seemed a little fierce, but basically I agree
with it. You will save yourself a lot of future headaches if you design
your class with a pure virtual interface (and methods using simple types).

Dave:

That may be the case, but the fact remains that the class whose methods
are invoked needs to contain a map member variable. At the moment, I'm
getting this annoying warning:

warning C4251: 'theManager::m_ signalMap' : class 'std::map<_Kty, _Ty>'
needs to have dll-interface to be used by clients of class 'theManager'

- which seems to imply that std::map can be exported - which contradicts
the (outdated) article on the MSN site. So do I heed the warning and
export the data type (preferred) or do ignore it (with potentially
disastrous consequences)?

[Grey Alien]

Never mind, I found the solution here:
http://caseys.kcfilms.com/2006/01/us...ross_dll_b.php

[Ben Voigt [C++ MVP]]

"Grey Alien" <gr**@andromeda .comwrote in message
news:1t******** *************** *******@bt.com. ..

>

Ben Voigt [C++ MVP] wrote:

>"Grey Alien" <gr**@andromeda .comwrote in message
news:uY******* **************@ bt.com...

>>>I have a class that contains a std::map variable. I need to export the
class via a DLL. the class looks something like this:

No you don't.

Yes I do. I know what I want.

Create an interface (class with pure virtual pointers),

>derive the implementation from it, and share only the interface. You do
that by putting the interface definition in a public header file. No
__declspec(dll export) statement is needed.

You are assuming that the DLL will be consumed by a C++ client. That is
not the case. Besides, how can you possibly use code in another
compilation unit if you don't link into it (either statically or
dynamically).?

If your client isn't C++, the prohibition on __declspec(dlle xport) of
classes becomes absolutely instead of just a really good idea.

What do you mean by "don't link into it"? You are creating a DLL, right?
"dynamicall y linked library" If you create an interface, then the compiler
links the interface v-table to the implementations . The client only needs
the interface definition.

[Ben Voigt [C++ MVP]]

"Grey Alien" <gr**@andromeda .comwrote in message
news:pK******** *************** *******@bt.com. ..

>

David Wilkinson wrote:

>Grey Alien wrote:

>>You are assuming that the DLL will be consumed by a C++ client. That is
not the case. Besides, how can you possibly use code in another
compilation unit if you don't link into it (either statically or
dynamically). ?

Grey:

You want to export a class containing an std::map and it will not be
consumed by a C++ client?

Ben's advice might have seemed a little fierce, but basically I agree
with it. You will save yourself a lot of future headaches if you design
your class with a pure virtual interface (and methods using simple
types).

Dave:

That may be the case, but the fact remains that the class whose methods
are invoked needs to contain a map member variable. At the moment, I'm
getting this annoying warning:

warning C4251: 'theManager::m_ signalMap' : class 'std::map<_Kty, _Ty>'
needs to have dll-interface to be used by clients of class 'theManager'
- which seems to imply that std::map can be exported - which contradicts
the (outdated) article on the MSN site. So do I heed the warning and
export the data type (preferred) or do ignore it (with potentially
disastrous consequences)?

There is no contradiction, both are correct. std::map should not be
exported, and because of that, it should not be used by clients of
"theManager ". Since it is a private implementation detail, why would that
present a problem? Clients aren't using it.