0

Possible Duplicate:
Does using references instead of pointers, resolve memory leaks in C++?

When I ask this question

Does using references instead of pointers, resolve memory leaks in C++?

A new question appears and I ask it in this post.

Does this code leak memory?

class my_class
{
  ...
};

my_class& func()
{
  my_class* c = new my_class;
  return *c;
}

int main()
{
  my_class& var1 = func();

  // I think there is no memory leak.
  return 0;
}
Community
  • 1
  • 1
Amir Saniyan
  • 13,014
  • 20
  • 92
  • 137
  • 1
    Yes. It is the same code you just gave us. It is terrible. Do not use `new` (unless you have a **very** good reason). – Kerrek SB Jul 21 '11 at 23:42
  • 3
    from the linked post, first answer "You haven't resolved any memory leaks. If you new, then you must delete." – Karoly Horvath Jul 21 '11 at 23:45
  • 4
    @Kerrek SB: sorry, but I disagree. Certainly objects on the stack are a very nice thing, but there are many legit reasons why `new` is a good idea. And there is a reason why many smart pointer classes exist that can exist on the stack and will automatically call `delete` on the kept instance when going out of scope. However, I agree that this code is terrible - among other things because of the ugly mix of reference and pointer. – 0xC0000022L Jul 21 '11 at 23:46
  • 3
    I don't understand why you had to post this again. Every answer to your first question said you hadn't resolved any leaks by returning a reference. – Praetorian Jul 21 '11 at 23:47
  • 3
    @STATUS: Modern C++ has so many nice ways to construct managed objects (I'm thinking of you, `make_shared`) that there should be _very_ few reasons to physically write out a `new` expression. OK, maybe if you're implementing your own library function (like `make_unique`). I'm not saying "never"... just *really carefully* :-) For a novice, I'm willing to bet that there's always a better, more idiomatic solution than a naked `new`! – Kerrek SB Jul 21 '11 at 23:49
  • 3
    [Valgrind](http://valgrind.org/) is your friend if you still doubt us. – jweyrich Jul 21 '11 at 23:49
  • @Kerrek SB: fair enough. I was thinking of some uses where certain limitations apply. I suppose you are right for the more general cases. :) – 0xC0000022L Jul 22 '11 at 01:58

4 Answers4

8

Yes, it does leak memory. Everything that was created by new has to be destroyed by delete. There's new in your code, but no delete. That immediately means that the newed memory is leaked.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • Not exactly. A smart pointer class (like: auto_ptr class) is a special case, it deletes memory automatically... so I hate it very much... – Stan Jul 22 '11 at 02:46
  • @Stan: Well, it deletes by using `delete`. From the core language point of view, `auto_ptr` is a user-defined type. There's not much difference in that respect between the situations when something is deleted implicitly by `auto_ptr` or explicitly by the user. – AnT stands with Russia Jul 22 '11 at 09:11
2

It does create a memory leak. Look at this example:

int main()
{
  my_class var1;
  my_class& var2 = var1;
  ...
}

Here the destructor for var1 will only be called once, if your assumtions were true, it would be called twice.

yms
  • 10,361
  • 3
  • 38
  • 68
  • 2
    Also, destructor being called by itself does not free the allocated memory. A call to `operator delete` needs to be made to do the actual freeing. Note that I'm not saying this needs to be done manually, the compiler does all this automagically. – Praetorian Jul 21 '11 at 23:50
0

Yes, you have to free every instance of an object u allocated using the 'new' operator or using the 'malloc' function.

m1o2
  • 1,549
  • 2
  • 17
  • 27
0

Make sure you clear the memory by using 'delete' when you are done.

M3NTA7
  • 1,307
  • 1
  • 13
  • 25