Jump to content
  • Advertisement
Sign in to follow this  
Uphoreum

std::string destruction == heap corruption?

This topic is 3245 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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)?

Share this post


Link to post
Share on other sites
Quote:
Original post by Uphoreum
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)?
I assume you are also aware of the problems with memory allocation/deallocation across DLL boundaries?

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.

Share this post


Link to post
Share on other sites
So, do people just avoid writing DLLs in C++ as much as possible? Does it not really happen much in the "professional world"?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!