Simple dynamic array question

[penguinFan]

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

[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.

[penguinFan]

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?

[Lindley]

Yes, that's fine.

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

[penguinFan]

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.

[laserlight]

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.

[Tronfi]

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:

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

[Lindley]

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.

[Lindley]

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.

[Tronfi]

Yes it will.

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

[TheCPUWizard]

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. .

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....

[Tronfi]

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. .

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!

[Lindley]

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.

[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 :-)

[TheCPUWizard]

> 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????

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.....