C++: When do I need to think about possible memory leaks?

Can I, with my own code, in C++ accidentally produce memory leaks without taking开发者_运维知识库 use of new and the malloc function? (and all other stdlib functions that allocate memory)

If you don't allocate anything on the heap then in general you won't have to worry about memory leaks.

If you don't call functions that allocate stuff on the heap, then all your data is held on the stack and will be destroyed when it is popped.

You should not use malloc in C++.

You need to worry about memory management whenever you attempt to manually manage dynamic (allocated using new) memory, whether you allocated it yourself, or you obtained it calling some function. (A function's documentation should tell you whether you need to free whatever it returns and which method to do so you need to use.)
What's more, you need to worry about every resource you acquire, be this memory, open files, locked mutexes, or whatever. You do not need to worry when you're employing techniques like RAII.

Many resources (strings, array, and other containers, files, etc.) already come wrapped in RAII classes. Use them and worry more about your algorithms, and less about resource management details.

• _strdup in CRT creates a buffer that should be deleted with free.
• There are some Windows SDK functions that could create buffers that you should delete. FormatMessage may create a buffer that should be deleted with LocalFree.
• If you catch structured exceptions and prevent the stack from unwinding then memory may leak.
• If you start a thread and don't let it finish properly before the main thread finishes then there will be memory leak (at the end of the application life, but it's still a leak).

It's hard without allocating heap memory (which is what malloc and new do), but not impossible. Let's say you were developing a game.

void playGame()
{
    ...
    showResults();
}

void showResults()
{
    ...
    if (playAgain)
        playGame();
    else
        exit(0);
}

In this example, the stack keeps growing as long as the user keeps choosing to play again. If the user chooses to play again, the playGame function is called, but since showResults hasn't returned, the original playGame also hasn't returned, so all the stack variables created there are still around. The new playGame instance creates new copies of those variables. If the player keeps playing again and again, you could run out of stack space. This might not technically be called a memory leak, but it's similar. Memory you are done using isn't being freed.

Memory on the heap gets only allocated with such function/operator (or other non-functions).

Of course if you're using some non-standard function, it could allocate memory in the heap. If they aren't bugged they should take care about deleting their stuff, or explicitly state in the documentation that function caller will take ownership of allocated data.

No. If you don't allocate memory, you can't leak it.

Typically if you need memory allocation using 'new' or 'malloc', RAII suggests that classes take explicit ownership that memory and clean it up in the destructor.

class blah {
  public:
    blah(): thing(null) { thing = new thing(); }
    ~blah() { delete thing; }
  private:
    thing *thing;
};

If you really need dynamic memory allocation (not explicitly owned) use a unique_ptr.

void func() {
  std::unique_ptr<W> because(new thing);
  because->because();
}