0

I was wondering, throughout a program I am using a lot of char* pointers to cstrings, and other pointers. I want to make sure that I have delete all pointers after the program is done, even though Visual Studio and Code Blocks both do it for me (I think..).

Is there a way to check is all memory is cleared? That nothing is still 'using memory'?

trincot
  • 317,000
  • 35
  • 244
  • 286
Martol1ni
  • 4,684
  • 2
  • 29
  • 39

6 Answers6

3

The obvious answer on Linux would be valgrind, but the VS mention makes me think you're on Windows. Here is a SO thread discussing valgrind alternatives for windows.

Community
  • 1
  • 1
pg1989
  • 1,010
  • 6
  • 13
1

I was wondering, throughout a program I am using a lot of char* pointers to cstrings

Why? I write C++ code every day and I very rarely use a pointer at all. Really it's only when using third party API's, and even then I can usually work around it to some degree. Not that pointers are inherently bad, but if you can avoid them, do so as it simplifies your program.

I want to make sure that I have delete all pointers after the program is done

This is a bit of a pointless exercise. The OS will do it for you when it cleans up your process.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • isn't this abit too judgemental? –  Mar 22 '12 at 00:16
  • @g24l: How so? I', not trying to be religious, but if you're essentially writing C in C++ then your doing yourself a disservice (and this from a guy who prefers C, but we're talking C++) – Ed S. Mar 22 '12 at 00:17
  • 1
    In 90% of cases it would be pointless, but heap fragmentation can evade an OS's efforts to de-allocate. Plus they are damned nasty to debug, so it's good to catch them early. – pg1989 Mar 22 '12 at 00:17
  • @pg1989: Can you explain that a bit further for me? I mean yeah, it's good not to write memory leaks, but I don't get the heap fragmentation reference. – Ed S. Mar 22 '12 at 00:18
  • The problem with the answer is that if the program is not releasing memory the fact that it is released when it shuts down is no consolation for the fact given this premise it is liable to be leaking memory while it is running. – Mark Fraser Mar 22 '12 at 00:19
  • @KenThompson: Right. I never said it was ok to leak memory, I said that it is pointless to care about it when your program ends. My first paragraph deals with the leaks themselves. – Ed S. Mar 22 '12 at 00:20
  • I don't think "don't use pointers" is a good answer for 'how to avoid memory leaks when I use pointers" – Mark Fraser Mar 22 '12 at 00:24
  • @KenThompson: It sure is if you can do without them. Honestly, if you are writing `Foo *f = new Foo()` all over the place you are not writing the best code you could be. – Ed S. Mar 22 '12 at 00:26
  • @KenThompson: ...and if this is "the" Ken Thompson... while I may disagree... it is an honor to disagree with you sir :D Of course... it is not – Ed S. Mar 22 '12 at 00:28
  • @EdS. I don't argue about what you say, but because you answer is judging against the question, i.e. saying your question is invalid because in case 1, 2, 3,...k , this does not happen, does not invalidate the question unless you explicitly show that k exhausts the feasible set. Otherwise, I am on your side. (fyi no downvote) –  Mar 22 '12 at 00:51
  • 1
    @g24l: Haha, ok, well if you're going to go all "formal proof" on me then what can I say? :D – Ed S. Mar 22 '12 at 00:53
  • @EdS. I am kinda new to C++, how do you substitute Foo *f = new Foo() ? How do you allocate dynamic memory? – David Frank Mar 22 '12 at 01:05
  • It's not a question of substituting it. You'll obviously need to dynamically allocate memory SOMEHOW. The best practices approach to this is to use something called RAII, or Resource Allocation is Initialization. Basically this abstracts away any explicit calls to 'new'. There are examples of RAII all over SO, or a google search will turn some stuff up. – pg1989 Mar 22 '12 at 01:16
  • @DavidFrank: What pg said. Essentially you wrap dynamic allocations inside of an object which, in its finalizer, deallocates the memory for you. So now you can allocate these objects with automatic storage duration and, when the leave scope, their destructor will run and the memory will be freed, without you writing any external calls to `delete`. – Ed S. Mar 22 '12 at 01:26
1

Visual Studio is an IDE. It isn't even there by the time your code is deployed. It doesn't release memory for you.

For what you want you can look into tools like this:

http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page

Mark Fraser
  • 3,160
  • 2
  • 29
  • 48
0

You might want to use some sort of a smart pointer (see the Boost library, for example). The idea is that instead of having to manage memory manually (that is call delete explicitly when you don't need the object any more), you enlist the power of RAII to do the work for you.

The problem with manual memory management (and in general resource management) is that it is hard to write a program that properly deallocates all memory -- because you forget, or later when you change your code do not realize there was some other memory that needed to be deallocated.

RAII in C++ takes advantage of the fact that the destructor of a stack-allocated object is called automatically when that object goes out of scope. If the destructor logic is written properly, the last object that references (manages) the dynamically allocated data will be the one (and only one) that deallocates that memory. This could be achieved via reference counting, maintaining a list of references, etc.

The RAII paradigm for memory is in a sense similar to the garbage collection of mamged languages, except it is running when needed and dictated by your code, not at certain intervals, largely independent from your code.

Attila
  • 28,265
  • 3
  • 46
  • 55
0

Unless you're writing driver code, there's absolutely nothing you can do with heap/freestore-allocated memory that would cause it to remain leaked once the program terminates. Leaked memory is only an issue during the lifetime of a given process; once a particular process has leaked its entire address space, it can't get any more for _that_particular_ process.

And it's not your compiler that does the uiltimate cleanup, it's the OS. In all modern operating systems that support segregated process address spaces (i.e. in which one process cannot read/write another process's address space, at least not without OS assistance), when a program terminates, the process's entire address space is reclaimed by the OS, whether or not the program has cleanly free()ed or deleted all of its heap/freestore-allocated memory. You can easily test this: Write a program that allocates 256 MBytes of space and then either exits or returns normally without freeing/deleting the allocated memory. Then run your program 16 times (or more). Shoot, run it 1000 times. If exiting without releasing that memory made it leak into oblivion until reboot, then you'd very soon run out of available memory. You'll find this to not be the case.

This same carelessness is not acceptable for certain other types of memory, however: If your program is holding onto any "handles" (a number that identifies some sort of resource granted to the process by the operating system), in some cases if you exit the program abnormally or uncleanly without releasing the handles, they remain lost until the next reboot. But unless your program is calling OS functions that give you such handles, that isn't a concern anyway.

phonetagger
  • 7,701
  • 3
  • 31
  • 55
0

If this is windows specific you can call this at the start of your program :-

_CrtSetDbgFlag(_crtDbgFlag | _CRTDBG_LEAK_CHECK_DF);

After including

#include <crtdbg.h>

And when your program exits the C++ runtime will output to the debugger a list of all memory blocks that are still allocated so you can see if you forgot to free anything.

Note that this only happens in DEBUG builds, in RELEASE builds the code does nothing (which is probabyl what you want anyway)

jcoder
  • 29,554
  • 19
  • 87
  • 130