preventing memory leak (case-specific)

Question

Consider the following situation:

SomeType *sptr = someFunction();
// do sth with sptr

I am unaware of the internals of someFunction(). Its pretty obvious that the pointer to the object which someFunction() is returning must be either malloc'ed or be a static variable.

Now, I do something with sptr, and quit. clearly the object be still on the heap which is possibly a source of leak.

How do I avoid this?

EDIT:

Are references more safer than pointers. Do the destructor for SomeType would be called if I do :

{
  SomeType &sref = *sptr;
}

Any insights.

Answer 1

What do you mean by quit? End the process? Your heap is usually destroyed when the process is destroyed. You would only get a leak potential after quitting the process if your asked the operating system to do something for you (like get a file or window handle) and didn't release it.

Also, functions that return pointers need to document very well whose responsibility it is to deallocate the pointer target (if at all), otherwise, you can't know whether you need to delete it yourself or you could delete it by accident (a disaster if you were not meant to do so).

If the documentation of the function doesn't tell you what to do, check the library documentation - sometimes a whole library takes the same policy rather than documenting it in each and every function. If you can't find the answer anywhere, contact the author or give up on the library, since the potential for errors is not worth it, IMHO.

In my experience most functions that return a pointer either allocate it dynamically or return a pointer that is based on the input parameter. In this case, since there are no arguments, I would bet that it is allocated dynamically and you should delete it when you're done. But programming shouldn't be a guessing game.

Answer 2

You need to read the documentation on someFunction. someFunction needs to clearly define the ownership of the returned pointer (does the caller own it and need to call delete or does someFunction own it and will make sure the the object is destructed sometime in the future).

If the code does not document it's behavior, there is no safe way to use it.

Answer 3

It's always a good habit to clean up after yourself, don't presume the OS will do it;

There's a good change your IDE or debugger will report memory leak when you quit your application.

What do you have to do ? Well, it depends, but normally you have to release the memory allocated by someFunction(), and the documentation will probably help you with that, either there's an API to release the memory or you have to do it manually with free or delete.

Max

Answer 4

The library should document this. Either you delete it explicitly after use or you call some release method which makes sure that object (and any other resources it points to*) doesn't leak.

(given a choice) Unless its a huge (in terms of memory) object, I would rather prefer a return by value. Or pass a reference to the function.

Answer 5

If someFunction returns an object for me it should be normal to have a pair function like someFunctionFree which you'll call to release the resources of the SomeType object. All the things needed should be found in the documentation of someFunction (mainly how the object can be freed or if the object is automatically freed). I personally prefer the corresponding deallocation function (a CreateObject/DestroyObject pair).

Answer 6

As others note it's up to the function to enforce it's ownership assumptions in code. Here's one way to do that using what's known as smart pointers:

#include <iostream>
#include <boost/shared_ptr.hpp>

struct Foo
{ 
  Foo( int _x ) : x(_x) {}
  ~Foo() { std::cout << "Destructing a Foo with x=" << std::hex << x << "\n"; }
  int x;
};

typedef boost::shared_ptr<Foo> FooHandle;

FooHandle makeFoo(int _x = 0xDEADBEEF) {
    return FooHandle(new Foo(_x));
}

int main()
{
    {
        FooHandle fh = makeFoo();
    }
    std::cout<<"No memory leaks here!\n";

    return 0;
}