new/delete

Hello, I had a question about what the difference is between delete and delete[]. Lets say for example I have this code:

Code:

---

char *tmp;
tmp = new char[100];
// ....
delete char;

---

Whats the difference between that, and this:

Code:

---

char *tmp;
tmp = new char[100];
// ....
delete []char;

---

Will they both free up the memory allocated to tmp? They both seem to compile and run without errors, just wondering if I'm causing a memory leak somewhere.

>Will they both free up the memory allocated to tmp?
No, delete [] will free all of the memory allocated to tmp, but delete will only free the memory for the first element. So yes, one would most certainly cause a memory leak.

-Prelude

Is this valid then?

Code:

---

int* MyPointer;
MyPointer = new int;
...
delete[] MyPointer;

---

>Is this valid then?
No, and technically neither is delete on an array allocated by new[]. What happens when you use the wrong delete is dependent on the implementation of the operators. Both are wrong, but the usual reaction to using delete on an array is that the first element is freed but the remaining memory is not. Of course, you can't rely on this. ;)

-Prelude

>but the usual reaction to using delete on an array is that the first element is freed but the remaining memory is not.<

Actually, it doesn't normally have any affect on the immediate de-allocation. Most delete implementations will end up calling free() or something similar which don't care if one or many elements have been allocated; they'll just free a block (as you're no doubt aware).

The problem is that in most implementations using delete on something new[]'d will result in only one destructor being called (instead of many) which could result in a secondary memory leak if you need to de-allocate in your destructor or other resource problems. Because primitives don't have destructors you *may* be able to get away with it; but as you point out, there's nothing in the standard that allows you to rely on this, so it's probably not a good idea.

--Under Microsoft Visual Studio 6.0--

Using Windows memory leak checking ( i.e. crtdbg.h ) it will NOT detect a memory leak given the following code..

Code:

---

int main( void )
{
  int *p = new int[500];

  delete p;

  return 0;
}

---

This is strange but what isn't using VS.

>Using Windows memory leak checking ( i.e. crtdbg.h ) it will NOT detect a memory leak given the following code..<

That's because there probably isn't a memory leak. Its still not a good idea if you want to ensure portability. What if MSVC++ 25.0 on Win XX uses completely different memory allocation routines?

By the way I knwo that the pointer will store the address of the first element of the array when we say:

Code:

---

int *p = new int[100];

---

So if we used this:

Code:

---

delete p;

---

it will only deallocate the first element so what will happen to the rest?

Theoretically, it just sits there wasting space until the program exits, at which point the OS will (hopefully) reclaim the memory...

Quote:

---

Originally posted by Sebastiani
Theoretically, it just sits there wasting space until the program exits, at which point the OS will (hopefully) reclaim the memory...

---

I thought the lack of this was why Windows usually starts lagging if you let it run for a long time... ;).

>I thought the lack of this was why Windows usually starts lagging if you let it run for a long time...
Windows does reclaim the memory, but not right away. So if you run a memory leak intensive program the computer will run slowly for several minutes.

-Prelude

Quote:

---

Originally posted by Prelude
>I thought the lack of this was why Windows usually starts lagging if you let it run for a long time...
Windows does reclaim the memory, but not right away. So if you run a memory leak intensive program the computer will run slowly for several minutes.

-Prelude

---

That's right....it does reclaim but not immeadiately....

do something like;

for(;;)new double[1000];

and catch the bad_alloc exception......your PC will be pretty slow for a few minutes.....on XP, there's an emergency utility that launches and tries to set things safe...but that's not instant.....

This seems to work, but i'm not sure.

Code:

---

int main()
{
        int *myInt = new int;

        *myInt = 5;

        delete [] myInt;
       
        return 0;
}

---

Anyway if it does work then why not always use the "[]" syntax for delete?

>Anyway if it does work then why not always use the "[]" syntax for delete?
Because it's wrong not to match the correct new with the correct delete. It may work for you, but that's not guaranteed, especially if you port to another compiler or system.

-Prelude

Quote:

---

Originally posted by The Dog
This seems to work, but i'm not sure.

Code:

---

int main()
{
        int *myInt = new int;

        *myInt = 5;

        delete [] myInt;
       
        return 0;
}

---

Anyway if it does work then why not always use the "[]" syntax for delete?

---

Because its undefined and not for what it was made for.....it may work in a small example, but it wont be trustworthy...if it was I doubt the Standards Board would have let the delete[] operator in

Remember that delete[] expects to call multiple destructors..... you might get away with it on a built in data type, but when you are doing it with class objects, you will probably fall foul at some point...so best bet - use delete[] for new[] and delete for new

<edit> Prelude got there first ;) </edit>