Re: passing stl through dll
"Alex Blekhman" <tkfx.REMOVE@yahoo.com> wrote in news:e0M8h6SBJHA.1180
@TK2MSFTNGP04.phx.gbl:
If nothing helps, then the common approach for this is to make a
wrapper class that uses Pimpl idiom and doesn't expose any STL
containers. You can read more about Pimpl idiom here:
"Compilation Firewalls"
http://www.gotw.ca/gotw/024.htm
I have to say that my experience indicates that exporting classes from dlls
binds the dll and exe so tightly you might as well not have bothered to
created the dll in the first place. I prefer to define some interfaces to
represent the classes implemented in the dll; export factory methods from
the dll and have those factories return pointers to the interfaces. What
this accomplishes is a clean separation of things in the dll and things in
the exe. That is, implementation classes in the dll, stay in the dll; it
also means that the exe can delete the object using its interface pointer
(assuming a virtual destructor) and memory correctly gets deallocated from
the dll; With some work, the factories can keep track of whether there are
still objects allocated from the dll (which can give you a clue as to
whether you can unload the dll or not); Factories and interfaces can be
versioned so that things can be backward compatible if necessary. I am
sure that I am fogetting other benefits, but you should seriously consider
a clean interface between your dll and your exe. The point of a dll, after
all is to be able to replace it or fix it without having to recompile
everything. Sadly with exported classes, you usually end up having to
rebuild everything whether it is strictly needed or not.
joe