std::string destruction == heap corruption?
I have a method in a DLL that I'm calling from an EXE which takes a plain old std::string. Even if the method does absolutely nothing, I get a "possible heap corruption" error when that passed in string gets destroyed when the method is finished. Could this issue be caused by my (unintentional) misuse of the heap somewhere else? It's a large DLL so I don't want to start looking if there is some other possible cause. All other usage of the DLL seems to work fine, so I don't know what I should look in to.
Any ideas on why a string being destroyed would corrupt the heap? I wish I could give more info but I have no idea what's going on.
Long story short: using templates across DLL boundaries is a bad idea. std::string is a typedef for std::basic_string<char, std::char_traits<char>, std::allocator<char> >, which means it's a template. If you do use try to use a std::string across boundaries, you'll need to make sure that everything is compiled with the exact same compiler options, that exact same compiler and that all the modules share the same standard library implementations both in terms of source and in terms of instances. You can also DLL export a template instance ( example), but it does not work with all template classes. On the whole, DLLs were designed for C interfaces, and using them with C++ is really a horrible hack.
Oh dear, I'm also passing std::vectors around :-/
Okay, I might have to find an alternative to using a DLL for this then. I would assume static libs don't have this issue? Static libs are pretty safe, correct?
Thanks!
EDIT: On second thought, is there any other problems besides templates and name mangling with C++ DLLs that I should know of? And, is it safer if I wrap the templates in another concrete class is that safe(er)?
Okay, I might have to find an alternative to using a DLL for this then. I would assume static libs don't have this issue? Static libs are pretty safe, correct?
Thanks!
EDIT: On second thought, is there any other problems besides templates and name mangling with C++ DLLs that I should know of? And, is it safer if I wrap the templates in another concrete class is that safe(er)?
Quote:Original post by UphoreumI assume you are also aware of the problems with memory allocation/deallocation across DLL boundaries?
EDIT: On second thought, is there any other problems besides templates and name mangling with C++ DLLs that I should know of? And, is it safer if I wrap the templates in another concrete class is that safe(er)?
Wrapping the std::containers in a concrete class doesn't help either - the size and layout of the std::containers may vary between releases. You can however wrap them in a class and hide them entirely using the PIMPL idiom.
So, do people just avoid writing DLLs in C++ as much as possible? Does it not really happen much in the "professional world"?
Using C++ in DLLs is fine and common, the problem is using C++ in the DLL interface. That is, it's fine to use whatever C++ you want in your DLL code, just as long as the users of your DLL don't see it.
Quote:Original post by Uphoreum
Okay, I might have to find an alternative to using a DLL for this then. I would assume static libs don't have this issue? Static libs are pretty safe, correct?
Hmm, perhaps not. I was creating a static library, and used an std::string (therefore, templates) as part of some of the method calls. I got a similar error message - 'possible heap corruption', which could well be due to the same problem.
I was going to post about this myself, but I found that abandoning the static library and inlining all the code got rid of the problem anyway. Still, the eventual aim was to wrap all of the code into a DLL so I can see myself running in the same problem. :(
Just to clarify, is this just a problem with templated types? So, as long as we just pass basic types - int, float, even a char* - we won't run into this problem?
Well, what I'm getting from this is that C++ is just not particularly good at being a DLL interface, or binary compatible with anything in general :D
I'm also having problems with exceptions across DLLs. I'm going to give a static lib a try and see how that works out. Otherwise I'll just have to figure out good way to inline the code like you did.
I'm also having problems with exceptions across DLLs. I'm going to give a static lib a try and see how that works out. Otherwise I'll just have to figure out good way to inline the code like you did.
Yeah, using exceptions across DLL boundaries is also a bad idea. You can pass around pointers to abstract base classes as interfaces safely, but that's really about it in terms of safe C++ constructs with DLLs. Otherwise, you should generally keep your interface to constructs you can express in C.
It's possible to use C++ features across DLL boundaries, but it's fragile and not worth the effort.
It's possible to use C++ features across DLL boundaries, but it's fragile and not worth the effort.
Quote:Original post by SiCrane
Yeah, using exceptions across DLL boundaries is also a bad idea. You can pass around pointers to abstract base classes as interfaces safely, but that's really about it in terms of safe C++ constructs with DLLs. Otherwise, you should generally keep your interface to constructs you can express in C.
Hence COM, although that can be a pain in it's own way. DLLs also introduce you to the wonderful world of DLL Hell, enjoy your version management.
Edit: my ability to spell is inversly proportional to the speed of this site on the iPhone (aka horrible)
[Edited by - Washu on August 14, 2009 9:16:19 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement