Sign in to follow this  
the dodger uk

c++ memory leaks detection

Recommended Posts

To expand a little on SiCrane's response:

Share this post


Link to post
Share on other sites
Are you using smart pointers such as std::auto_ptr or std::tr1::shared_ptr?

These will help prevent almost all memory leak issues and really are the way to go in modern C++. Afterall, prevention is better than cure ;) Edited by Karsten_

Share this post


Link to post
Share on other sites

Are you using smart pointers such as std::auto_ptr or std::tr1::shared_ptr?

These will help prevent almost all memory leak issues and really are the way to go in modern C++. Afterall, prevention is better than cure ;)

std::auto_ptr was designed badly and has been deprecated. It was designed badly because they were trying to add the features that std::unique_ptr has, before they had the actual capabilities (move semantics) to do so properly, so they worked around the problem instead of fixing the problem (the problem being a difficult and huge change, but one they successfully made in C++11). One side effect of 'working around' the problem is std::auto_ptr can't be used in most standard library containers. ohmy.png

Share this post


Link to post
Share on other sites

If you like doing it yourself there is always the possibility of overriding global new and delete operators (normal and array version) and possibly use some makro magic to include __FILE__ and __LINE__ in the calls inside of files where you expect errors (that needs 1 more operator for all variants), when doing a debug build. Then collect data in there and print out a log for calling wrong operator delete, deleting twice and remaining allocations at end of your program.

Though using some premade library would probably give you better results.

Share this post


Link to post
Share on other sites

If you like doing it yourself there is always the possibility of overriding global new and delete operators

I don't terribly recommend this approach. It can play havoc when your project incorporates DLLs, as the correct new/delete operator isn't always used across DLL boundaries...

Share this post


Link to post
Share on other sites

Yeah as said I would only do that in a debug build not on your release.

Also its safer anyways to not allocate anything inside one dll and deallocate it outside and then there should be no problem. If there is one, it just brought a possible bug to surface, which was the point of overwriting it.

Share this post


Link to post
Share on other sites

std::auto_ptr was designed badly and has been deprecated.

Yeah true, so can't really be called "modern C++". But it is better than using "raw" pointers for everything I suppose.

<offtopic>
Though personally I always find it a tossup between using the deprecated auto_ptr or dragging in boost as a dependency when tr1 isn't available.
</offtopic>

My favorite solution though is to just write code modules in a cross platform manner and use Valgrind in a VM to test them before release. Especially when developing on embedded platforms or OpenBSD.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this