DLLs and the STL (Visual Studio)

[Ebonair]

I'm creating a simple dynamic link library. I have this:

#ifdef BUILDING_MATHHELPER_DLL
    #define MH_INTERFACE __declspec(dllexport)
#else
    #define MH_INTERFACE __declspec(dllimport)
#endif

class MH_INTERFACE Point2D
{
    public:
        //constructors
        Point2D(void);

    private:
        std::vector<int> testVector;
};

Now, it's not liking testVector, I get

class 'std::vector<_Ty>' needs to have dll-interface to be used by clients of class 'MHTypes::Point2D'

I've looked at various online articles on "template instantiation declaration to export the STL class instantiation from the DLL", but it seems very hairy, and might not work on all STL containers.

So I just wrote a small wrapper class around Point2D, called Point2D_Int and exported it with __declspec(dllexport). Point2D_Int contains a member variable that's a pointer to the actual Point2D, which contains the std::vector. The compiler warning went away!

Is this a good idea? Is it alright to use the STL in a DLL's internal classes like this? Will I end up with weird linker errors later on?

[kbw]

Ignore the error. It's relevant if you're exporting data, which I believe you should NEVER do.

The data is private, you never access it directly in the client code, so forget about it.

[guestgulkan]

I was going to point him here:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;168958

[Ebonair]

guestgulkan: I've read through that page a few times, where I found:

"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."

If I can only do vectors, then it isn't a solution I can generally apply to my code, which has all sorts of stl::containers as member variables.

This page covers the problem in even more detail: http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html I don't claim to fully understand it all.

kbw: By 'exporting' data, do you mean I should never have a publicly-exposed member variable? What if I write an accessor for it?

[kbw]

Exporting functions is fine.

Exporting classes with private data is fine. And that goes for any data; vectors, maps, sets, your own classes that have these things ...

The issue with with how the C/C++ runtime is shared. Of course, they can only share it if they link to it at runtime. Binding to the static runtime libs is unhelpful because:
1. Each module has a copy of the C/C++ runtime; that's lots of duplicate code.
2. You get different heaps for different modules--that's really really bad.

[Ebonair]

That's what I needed to know. Thank you very much!