What happens if i don't free/delete dynamically allocated arrays?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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? Something like: