Simple dynamic array question

I'm wondering how "delete[]" works, and if the following code does what I expect:
string* A = new string[10];
string* B = new string[20];
// now swap
string* temp = A;
A = B;
B = temp;
// do interesting stuff, then delete
delete []A;
delete []B;

I'm hoping the above "works" and that the correct sizes of arrays are deleted.

Obviously "delete[]" knows how many elements to delete somehow. But where is this stored? With the ptr? In the heap array allocation?

Storing with the ptr violates what I know about C/C++ ptrs. Storing with the heap array allocation means that normal ptr arithmetic for array elements would break. Is it maybe stored as a negative offset from the first array element?

Many thanks for any enlightenment. (Normally, I would just use a Vector or similar, but I want to understand what's going on behind the scenes here.)

-- penguinFan

The Standard says nothing about where the size should be stored, so this depends on your compiler. For example, it can be stored just before the allocated memory. But it's never IN the array.

OK, got it. But is my code correct? A simplified version goes this way:
string *A = new string [20];
string *B = A;
delete [] B;
Is the system going to be able to figure out how big the array is that B points to?

Yes, that's fine.

You should consider using std::vector rather than using dynamic arrays directly. It will make your code cleaner.

Thanks for the confirmation!

BTW I do use std::vector in normal life. I'm just trying to understand how dynamic arrays work here.

A related question: if the extent of a dynamic array is guaranteed to be knowable to the run-time, why isn't it accessible via an API call to the programmer? (I know, you didn't design the language ... but maybe there's a philosophical reason?)

Thanks again.

Quote:

---

Originally Posted by penguinFan

A related question: if the extent of a dynamic array is guaranteed to be knowable to the run-time, why isn't it accessible via an API call to the programmer?

---

But it is, via the capacity() member function.

EDIT:
Oh wait, you are talking about the dynamically allocated arrays managed manually, rather than dynamic array functionality provided by std::vector. In that case, perhaps a possible answer is that such knowledge is likely to be implementation dependent, and hence unsuitable for a standard library.

Code:

---

string *A = new string [20];
string *B = A;
delete [] B;

---

Do you really think that delete [] B will delete the array? It will not. I will just delete the pointer *B, with a size of 4 bytes.

Try this:

Code:

---

int *v=new int[10];
v[1]=7;
int *ptrv=v;
delete [] ptrv;
cout<<v[1]<<endl;

---

Eh, I can't think of any reason not to provide a "query allocated size" mechanism. The information has to be there after all. It just wasn't included in the language for whatever reason.

There actually is one for malloc()ed memory, but it shouldn't be used with new'd memory since there's no guarantee that new uses malloc internally.

Quote:

---

Originally Posted by Tronfi

Code:

---

string *A = new string [20];
string *B = A;
delete [] B;

---

Do you really think that delete [] B will delete the array? It will not.

---

Yes it will.

Quote:

---

Originally Posted by Lindley

Yes it will.

---

Why you think so? After delete the pointer, v[1] is still accesible.

Quote:

---

Originally Posted by yzaykov

The Standard says nothing about where the size should be stored, so this depends on your compiler. For example, it can be stored just before the allocated memory. But it's never IN the array.

---

Most compilers store it in the lower left back corner of the computer. If you look with a microscope you may be able to see them. :D :D ;).

And Lindley is 100* correct in that "delete []" will delete the entire array. If the array elements have a destructor they wil each be fired (of course this does not apply to POD or raw pointers).

ps: before the array is a common location also. Qucik test: new something that is not an array, then new an array, look at the addresses and do some math....

Quote:

---

Originally Posted by TheCPUWizard

Most compilers store it in the lower left back corner of the computer. If you look with a microscope you may be able to see them. :D :D ;).

And Lindley is 100* correct in that "delete []" will delete the entire array. If the array elements have a destructor they wil each be fired (of course this does not apply to POD or raw pointers).

ps: before the array is a common location also. Qucik test: new something that is not an array, then new an array, look at the addresses and do some math....

---

And I guess int doesn't have destructor, does it?

Thank you!

More to the point, destructing anything, POD or not, isn't guaranteed to make the values in that region of memory change at all. All it's guaranteed to do is make it inappropriate for you to touch that memory.

> More to the point, destructing anything, POD or not, isn't guaranteed to make the values in that
> region of memory change at all. All it's guaranteed to do is make it inappropriate for you to
> touch that memory

I would hope that it would guarantee that the dynamic storage will not become a memory leak :-)

Quote:

---

Originally Posted by penguinFan

> More to the point, destructing anything, POD or not, isn't guaranteed to make the values in that
> region of memory change at all. All it's guaranteed to do is make it inappropriate for you to
> touch that memory

I would hope that it would guarantee that the dynamic storage will not become a memory leak :-)

---

WHY do you think it should????

Code:

---

class Foo
{
  public:
      Foo() { m_Leak = new char[100]; }
      ~ Foo() { }
  private: char *m_Leak;
}

Foo *fp = new foo[100];
delete [] fp;

---

The bold line can not possibly prevent the leakage.....

>The bold line can not possibly prevent the leakage.....

Well, OK, but that seems like splitting hairs. The storage for m_leak will be a leak (somewhere else in freestore), but the array elements themselves (fp) will not be a leak. Which is what I meant.

Quote:

---

Originally Posted by penguinFan

Well, OK, but that seems like splitting hairs.

---

Yes, but then you were also splitting hairs by refusing to read into what Lindley implied ;)

That's why I smiley'd it :-)

Quote:

---

Originally Posted by laserlight

Yes, but then you were also splitting hairs by refusing to read into what Lindley implied ;)

---

Splitting Hares is frowned upon...It can also get very messy. :eek:

> Splitting Hares is frowned upon.

I get feral rabbits in my back yard. The neighbourhood cats are doing their best to open up their abstraction boundaries.

Quote:

---

Originally Posted by penguinFan

> Splitting Hares is frowned upon.

I get feral rabbits in my back yard. The neighbourhood cats are doing their best to open up their abstraction boundaries.

---

Living in the heart of the city...not too many Rabbits...but lots of "Rat Bits"... :sick: