DLL with STL Woes

Started by
11 comments, last by iMalc 19 years, 3 months ago
Oh I agree - its just you have to jump through a few hoops in order to use some basic things, such as vector. If you use a UDT, you must overload the < and == operator because those tow are used in STL. Furthermore, as MSDN says, you must explicitly instaniate those classes in order to export and use them. I know I have had trouble using string when it was in a parameter list (generated in .dll memory I assume the problem was), so I had to convert to all char*'s. It's too bad it wasn't designed to easily integrate into .dlls :(.
Advertisement
Why would you want to use a .dll? You can't throw exceptions out of them, right? :-( I'd use a static lib... What are the benefits of a dll?
Quote:Original post by joanusdmentia
This is true, but it doesn't mean you can't use the STL containers. The same code will be generated in both the DLL and EXE for the container, so reading from a list in an EXE that was created in a DLL isn't a problem. Problems occur when you modify the list (adding/removing nodes, changing the value of a node is OK) as this could result in allocating or releasing memory on different heaps (the EXE's and the DLL's)....things start to go *splat*.
But you should never have to access the container from both parts. A container can easily only be used only entirely within the DLL. The EXE doesn't need to know (and shouldn't need to know) what kind of data structure the data is held in inside the DLL. It comes down to basic OO design doesn't it? You can use STL entirely within the DLL, and that is what it makes sense to do IMHO. I don't really see that there is a problem.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

This topic is closed to new replies.

Advertisement