4

This code is not written bt me! In the class WebServer we overload +=operator. The class uses dynamically allocated array of objects of type WebPage(another class, composition) defined as WebPage *wp;

WebServer & operator +=( WebPage webPage ) {
WebPage * tmp = new WebPage [ count + 1];
for (int i = 0; i < count ; i ++)
tmp [i] = wp[i];
tmp [ count ++] = webPage ;
delete [] wp;
wp = tmp;
return * this ;
}

So we create a new array of dynamically allocated WebPages with extra space for one object, then we assign them the values that wp held, and then the object that we wanted to add to the array. So if i remove delete[] wp; the program still works ok. So what happens if i remove that line of code? And also wp=tmp, what does that mean, is wp only a new name for that dynamically so it would suit the name in the class, but the location in memory is still the same? Or?

Stefan Stojkovski
  • 479
  • 2
  • 8
  • 17
  • If you don't free/delete dynamically allocated arrays they don't get freed/deleted. That's all. – R. Martinho Fernandes Aug 28 '13 at 11:30
  • 5
    Use `vector` it deletes itself automatically and has a push_back function to add new elements to the existing array. – Neil Kirk Aug 28 '13 at 11:32
  • When you don't delete dynamically allocated memory a terrible curse happens and your fingers and whatever you touch turns into gold...fish. So you cannot write anymore code. And you have to keep your hands underwater. – erelender Aug 29 '13 at 10:35

6 Answers6

7

So if i remove delete[] wp; the program still works ok. So what happens if i remove that line of code?

You have introduced a memory leak. Each time this operator is invoked the process will waste some portion of its address space until it ultimately runs out of memory.

And also wp=tmp, what does that mean, is wp only a new name for that dynamically so it would suit the name in the class, but the location in memory is still the same? Or?

wp is presumably a member (an instance variable) of WebServer that holds instances of the WebPage objects it serves. So that line is replacing the previous array of web pages with a new value (that includes the web pages just added to the server).

Presumably there are other member functions of WebServer that read the values inside wp and do things with them.

As a general note, you should be aware that this code is extremely badly written because it is not even remotely exception safe, it's doing work that could be avoided with a reasonably smarter implementation and most of all it is using homebrew code instead of standard language facilities like std::vector.

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
Jon
  • 428,835
  • 81
  • 738
  • 806
  • 1
    I'd like to give another +1 for the last line of your post. That code really makes me shudder. It is not only difficult to read, but also inefficient during runtime and was inefficient to write in the presence of the standard library (vector). – ogni42 Aug 28 '13 at 11:50
  • Wait wait, so we free wp, and then with wp=tmp we occupy it again with the one exrea object and temp destroys itself when function ends? – Stefan Stojkovski Aug 28 '13 at 16:59
  • And also how would you write the code, i don't know any other way to write this so... – Stefan Stojkovski Aug 28 '13 at 17:01
  • @StefS: `tmp` does not destroy itself because it is a dumb pointer. The memory it points to also does not destroy itself because it was allocated with `new[]`; its lifetime does not end until `delete[]` is called, which will happen on the next invocation of this operator (`delete[] wp`). – Jon Aug 28 '13 at 19:13
  • @StefS: A much better way of writing this would be to have an `std::vector` instead of `wp`; the operator would not only be much more robust but also an one-liner: `vector.push_back(webPage); return *this;`. But of course this means that all the code that touches `wp` will have to change accordingly. – Jon Aug 28 '13 at 19:16
5

Either you get:

  • Just a memory leak or
  • A memory leak with undefined behavior depending on whether the destructor of your class has code with side effects.

In this case it just causes a memory leak. However, depending on whether the same unallocated memory gets reused for other objects you might end up with a Undefined behavior.

C++11 Standard: [basic.life] (3.8 Object lifetime), Para 4:

A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.

Alok Save
  • 202,538
  • 53
  • 430
  • 533
2

Not calling delete means that free doesn't get called and the destructor doesn't get called. The implications of not calling free on the allocated memory is a memory leak -- your program no longer can use that memory. If this persists, over time your program could very well crash because it's run out of memory, The implications of not calling the dtor means any other resource (more memory, db connections, etc) your array uses are also lost.

Paul Evans
  • 27,315
  • 3
  • 37
  • 54
  • 1
    +1 for mentioning other resources that might be released in the destructor in RAII style. – Hulk Aug 28 '13 at 11:45
2

If you don't delete something, you have a memory leak. Memory leaks are in the "It keeps working for quite some time, but then fails" category of broken code. It makes them hard to deal with, because the problem happens a long time after the original error, and it's often hard to identify where/how the memory got leaked, and the application fails at some "random" place when there is no more memory available.

It is also bad for OTHER applications when an application leaks memory, because there will be less memory available to other applications.

Depending on the scale of the leak, it may end up being one of those things that causes your application to get poor reputation for reliabilty ("It crashes after two days") or it may end up being a killer for your app ("Doesn't work when I tried a little more complex use-case"). Or it may just be that after two years of continous use, the application has grown its memory usage for 64MB to 72MB, because the leak is so tiny you don't really notice, in the whole scheme of things.

But having a memory leak is never a good thing, and in many cases a really bad thing.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
0

Objects allocated with new stay on the heap until they are deallocated with delete. If you don't delete them, they will remain there (but won't be accessible -> this is called memory leak) until your process exits, when the operating system will deallocate them.

kol
  • 27,881
  • 12
  • 83
  • 120
0

It may be a bad code, but i don't know to use strings and vectors(idk for what reason they didn't taught us), but i still don't quite understand. Is it that the, fist with WebPage * tmp = new WebPage [ count + 1]; we occupy new space, then we transfer the data, then we delete wp. So what does wp = tmp; do. Does it only give the name wp to the space occupied by tmp so that it would correspond to the name in the class, but the addresses of those objects are the same with those that tmp used, but different with those that wp before being deleted used?enter image description here Something like:

Stefan Stojkovski
  • 479
  • 2
  • 8
  • 17