delete[]
Martijn Mulder
{
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?
joshua...@gmail.com
> 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
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
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!
--
Phlip
blargg
> void main()
int main()
Via a similar way that it knows that a has the value 10 below, and then
later on the value 100:
int a = 10;
int b = 100;
a = b;
Martijn Mulder
>> 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.
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
blargg
> >> How does the
> >> runtime know that first *a points to an array of 10 elements and later to
> >> an
> >> array of 100 elements?
> >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.
For types with trivial (no) destructor, the runtime does NOT need to store
the size of the array. If you want to know the size later, use
std::vector.
Bo Persson
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
joshua...@gmail.com
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
> >> How does the runtime know that first *a points to an array
> >> of 10 elements and later to an array of 100 elements?
The correct answer here is that it doesn't.
> >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.
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.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34