delete[]

[Martijn Mulder]

void main()
{
int*a=new int[10];
int*b=new int[100];
delete[]a;
a=b;
delete[]a;
}

In the code above, is de new'd memory correctly deleted? How does the
runtime know that first *a points to an array of 10 elements and later to an
array of 100 elements?

 

[joshuamaurice]

void main()
{
 int*a=new int[10];
 int*b=new int[100];
 delete[]a;
 a=b;
 delete[]a;

}

In the code above, is de new'd memory correctly deleted?
Yes

How does the
runtime know that first *a points to an array of 10 elements and later to an
array of 100 elements?

Magic.

Usually one of two approaches is employed (abbreviated):

1- When you allocate a chunk of 100 bytes, the runtime actually
allocates 104 bytes and stores the allocation size in the first 4
bytes, then returns the allocation pointer + 4 bytes. When you
deallocate it, the runtime looks at this header by taking the pointer
- 4 to get the allocation size.

2- A table is kept, mapping each allocation to its size.

 

[Puppet_Sock]

void main()
{
 int*a=new int[10];
 int*b=new int[100];
 delete[]a;
 a=b;
 delete[]a;

}

In the code above, is de new'd memory correctly deleted? How does the
runtime know that first *a points to an array of 10 elements and later to an
array of 100 elements?

Technically, since the language does not define
*how* the implementation does it, it's off topic
here. As far as coding what you need to know is,
the calls to new will return different values
(always presuming that the allocation actually
works, that there is enough memory left) and that
the implementation knows how to find the memory
chunk through those values. And how to do things
like offsets from pointers to elements of an
allocated block, and so on.
Socks

 

[Phlip]

void main()

'void main' inhibits Republicans from attacking each other by accident. Always
use 'int main'.

 

[Phlip]

Technically, since the language does not define
*how* the implementation does it, it's off topic
here.

Incorrect. Comparing implementations is a very important role for this
newsgroup, and one that we cannot trust to _any_ vendor-specific forum!

 

[Martijn Mulder]

How does the

Magic.

Usually one of two approaches is employed (abbreviated):

1- When you allocate a chunk of 100 bytes, the runtime actually
allocates 104 bytes and stores the allocation size in the first 4
bytes, then returns the allocation pointer + 4 bytes. When you
deallocate it, the runtime looks at this header by taking the pointer
- 4 to get the allocation size.

2- A table is kept, mapping each allocation to its size.

If the size of the array is know by the run-time, what prevents C++ from
exposing this value to the programmer? It can be used to implement bounds
checking on array access, or help with generic constucts.

 

[Ioannis Vranos]

If the size of the array is know by the run-time, what prevents C++ from
exposing this value to the programmer? It can be used to implement bounds
checking on array access, or help with generic constucts.

I *suppose* that requiring a facility to provide the size of an array allocated at the heap at *run-time*,
would probably impose some requirements to the compile writers that would be a problem for the efficiency
usually required from low-level code.

The normal way is to use the standard library high-level containers and other facilities, and not manage your
resources manually. For example you may use std::vector.

All standard library containers provide a member function size() that provides the current number of their
stored elements.


Also have a look at Resource Acquisition Is Initialisation (RAII) technique. All standard library containers
are using RAII.





--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[Bo Persson]

If the size of the array is know by the run-time, what prevents C++
from exposing this value to the programmer? It can be used to
implement bounds checking on array access, or help with generic
constucts.

It might be that it is the operating system that keeps the tables. We
don't know if the run-time ALWAYS knows the array size.


Bo Persson

 

[joshuamaurice]

If the size of the array is know by the run-time, what prevents C++ from
exposing this value to the programmer? It can be used to implement bounds
checking on array access, or help with generic constucts.

Specifically, the runtime for arrays with trivial destructors may not
store the exact size. There are several heap algorithms which do not
keep track of the exact size. It may round up the size to the next
power of two for algorithmic efficiency reasons, aka it might not
actually know the exact size, just an upper bound on the size. Thus we
do not impose this additional cost on the runtime and pass the buck to
the programmer, or tell the programmer to use std::vector.

 

[James Kanze]

The correct answer here is that it doesn't.

I think what you're talking about (and maybe what the original
poster actually meant to ask) is how the system knows the size
of the memory to be freed. And it's a bit more complicated than
what you suggest---alignment considerations play a role in the
first method, for example, and the size may be implicit, rather
than explicit (the "hidden" data may contain a pointer to the
next block, rather than the actual size). As for the second,
rather than mapping each allocation, the implementation is
likely to maintain separate pools for each size it allocates
(pre-defining a certain number of sizes, and rounding the
request up to the next predetermined size), and use the high
order bits of the address to determine in which pool the memory
resides.

If the size of the array is know by the run-time, what
prevents C++ from exposing this value to the programmer?

It's not. Generally, the system does "know" the size of the
allocated memory, but that's all. And depending on the
allocation algorithm used, this can be considerably larger than
the number of elements times the size of each element.