-1

Assume that there is a user defined class Student. Consider the following two functions:

Student someFunc1() {
    return *(new Student("John",25)); 
}

Student& someFunc2() {
    return *(new Student("John",25)); 
}

Without going into the details as to why they have been implemented the way they have been, are they both correct? Somebody told me that there would be a memory leak but how come?

abcde
  • 505
  • 1
  • 5
  • 8
  • 6
    The first one has an irrecoverable memory leak. The second one has a potential memory leak but the caller can still de-allocate. I suggest spending some time learning C++ from some good books. It will take you 300 years to learn one trivial question at a time. – juanchopanza Feb 11 '15 at 20:53
  • 1
    Why don't you try it? Smells like homework to me... – Ulrich Eckhardt Feb 11 '15 at 20:57
  • Please explain what is going on in the second function. Is it equivalent to returning a pointer? – abcde Feb 11 '15 at 20:59
  • Well, I did and finished my homework just fine. I just started thinking beyond it. If you're going to chastise me for that, then I'll stop learning C++ and learn Java instead. That will be bad, bad for C++. – abcde Feb 11 '15 at 21:00
  • Which part is unclear to you? Which parts are clear? If you tried to run that code, what did you find out? – Ulrich Eckhardt Feb 11 '15 at 21:00
  • 1
    No big loss when you are so easily turned off of C++. As @juanchopanza mentioned getting a book is the way to go. Otherwise you'll always have misconceptions how C++ works and as a result will create bad code. – mfuchs Feb 11 '15 at 21:07
  • Have a look at [this](http://stackoverflow.com/questions/57483/what-are-the-differences-between-a-pointer-variable-and-a-reference-variable-in), it should answer alot of your future questions about pointers/references. – Slyps Feb 11 '15 at 21:10
  • 2
    @AnonymousAndy: Manual resource management can be complex and error prone. I suggest you stop using `new` until you know the language better. There are reasons why we have `std::string` and containers like `std::vector`, they manage memory and hide this complexity so you can get on with your actual programming logic. – Blastfurnace Feb 11 '15 at 21:12

3 Answers3

6

Yes, there certainly is something wrong.

someFunc1() will definitely cause a memory leak, because the memory address of the allocated object is lost.

someFunc2() will cause a risk for a memory leak, because the user of the function has to remember to delete the returned object with a weird syntax (delete &object).

Neither of them is good C++. A correct version would be:

Student someFunc3() {
    return Student("John",25); 
}
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
Emil Laine
  • 41,598
  • 9
  • 101
  • 157
  • @AnonymousAndy The second function returns a _reference_ (`&` syntax) to the newly allocated object. It's almost equivalent to returning a pointer, except that the variable is not a memory address and without the pointer dereference syntax hassle, and `nullptr` is not possible using references. – Emil Laine Feb 11 '15 at 21:02
3

The first function allocates an object, that dereferences it and returns. By default, return does a copy of object. Thus the originally allocated object still exists, but is not accessible anymore. Which is a memory leak by definition.

In the second case, however, the reference to the allocated object is returned rather than a copy. This way, the caller may still take an address of the object and delete it.

ftynse
  • 787
  • 4
  • 9
  • An optimizing compiler may however apply copy elision in the first case. But there is no guarantee it will. – ftynse Feb 11 '15 at 21:27
0

When you declare new variables in c++ they are allocated on the heap. When the variables go out of scope (like when the program ends), the memory stays allocated, unless you explicitly delete them in your code.

You should read this

mstbaum
  • 434
  • 2
  • 11