bstr and delete[]

[yufufi]

Hello,

How does delete[] know how much memory to deallocate from the given
pointer? AFAIK this informations is put there by new[]. new[] puts the
size of the allocated memory before the just before the beginning of the
array. But I couldn't find this information by looking at the memory.
(Via VS2005 - C++)

My second questions is, if there is a mechanism to know how much memory
is allocated for the array, why don't we use it for things like bstr?
Only thing I can think of is you may go and allocate a big chunk of
memory with new[] and use it for more then one bstr's and such. (However
i'm not even sure how you can do it with bstr since you have to use
::SysAllocString)

Thank you in advance,

Furkan

[mlimber]

On Feb 20, 2:38 pm, yufufi <yufufi_at_comcast.netwrote:

How does delete[] know how much memory to deallocate from the given
pointer? AFAIK this informations is put there by new[]. new[] puts the
size of the allocated memory before the just before the beginning of the
array. But I couldn't find this information by looking at the memory.
(Via VS2005 - C++)

http://www.parashift.com/c++-faq-lit...html#faq-16.14

My second questions is, if there is a mechanism to know how much memory
is allocated for the array, why don't we use it for things like bstr?
Only thing I can think of is you may go and allocate a big chunk of
memory with new[] and use it for more then one bstr's and such. (However
i'm not even sure how you can do it with bstr since you have to use
::SysAllocString)

This part is off-topic here. Try a Microsoft group (cf. the list at
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9)

Cheers! --M

[yufufi]

mlimber wrote:

On Feb 20, 2:38 pm, yufufi <yufufi_at_comcast.netwrote:

>How does delete[] know how much memory to deallocate from the given
pointer? AFAIK this informations is put there by new[]. new[] puts the
size of the allocated memory before the just before the beginning of the
array. But I couldn't find this information by looking at the memory.
(Via VS2005 - C++)

http://www.parashift.com/c++-faq-lit...html#faq-16.14

>My second questions is, if there is a mechanism to know how much memory
is allocated for the array, why don't we use it for things like bstr?
Only thing I can think of is you may go and allocate a big chunk of
memory with new[] and use it for more then one bstr's and such. (However
i'm not even sure how you can do it with bstr since you have to use
::SysAllocString)

This part is off-topic here. Try a Microsoft group (cf. the list at
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9)

Cheers! --M

The page you point to answers the question of "How many objects to
destruct?" which is a little bit different then what I'm asking.

In the sample code for one of the delete[] implementations:

// Original code: Fred* p = new Fred[n];
char* tmp = (char*) operator new[] (WORDSIZE + n * sizeof(Fred));
Fred* p = (Fred*) (tmp + WORDSIZE);
*(size_t*)tmp = n;
size_t i;
try {
for (i = 0; i < n; ++i)
new(p + i) Fred(); // Placement new
}
catch (...) {
while (i-- != 0)
(p + i)->~Fred(); // Explicit call to the destructor
operator delete[] ((char*)p - WORDSIZE);
throw;
}

'n' used to decide number of destructor calls needed. But in the line
one before the last:

operator delete[] ((char*)p - WORDSIZE);

Still compiler is presented with a pointer to an array(which in it's
first WORDSIZE has n)

1) Isn't this an infinite loop(recursive)?
2) If the second one is somehow a different delete[], will it act like:
operator delete[] (*p)
{
arraySize = (((WORDSIZE *)p)[0])*sizeOf(Fred)
InternalDelete(p,arraySize);

}

Thank you,

[Mark P]

yufufi wrote:

mlimber wrote:

>On Feb 20, 2:38 pm, yufufi <yufufi_at_comcast.netwrote:

>>How does delete[] know how much memory to deallocate from the given
pointer? AFAIK this informations is put there by new[]. new[] puts the
size of the allocated memory before the just before the beginning of the
array. But I couldn't find this information by looking at the memory.
(Via VS2005 - C++)

http://www.parashift.com/c++-faq-lit...html#faq-16.14

>>My second questions is, if there is a mechanism to know how much memory
is allocated for the array, why don't we use it for things like bstr?
Only thing I can think of is you may go and allocate a big chunk of
memory with new[] and use it for more then one bstr's and such. (However
i'm not even sure how you can do it with bstr since you have to use
::SysAllocString)

This part is off-topic here. Try a Microsoft group (cf. the list at
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9)

Cheers! --M

The page you point to answers the question of "How many objects to
destruct?" which is a little bit different then what I'm asking.

In the sample code for one of the delete[] implementations:

You're confused. This is not a delete[] implementation-- this is a
new[] implementation. The call to operator delete[] is in a catch block
which is there to prevent a memory leak in case one of the constructor
"calls" to Fred (via placement new) fails.

>
// Original code: Fred* p = new Fred[n];
char* tmp = (char*) operator new[] (WORDSIZE + n * sizeof(Fred));
Fred* p = (Fred*) (tmp + WORDSIZE);
*(size_t*)tmp = n;
size_t i;
try {
for (i = 0; i < n; ++i)
new(p + i) Fred(); // Placement new
}
catch (...) {
while (i-- != 0)
(p + i)->~Fred(); // Explicit call to the destructor
operator delete[] ((char*)p - WORDSIZE);
throw;
}

'n' used to decide number of destructor calls needed. But in the line
one before the last:

operator delete[] ((char*)p - WORDSIZE);

Still compiler is presented with a pointer to an array(which in it's
first WORDSIZE has n)

1) Isn't this an infinite loop(recursive)?

No. As I already said, this is an implementation of new[] not of
delete[]. More to the point of your question, there's a distinction
between new[] and operator new[], and likewise for delete[] and operator
delete[]. The first versions not only allocate (or deallocate) memory
via operator new[] (or operator delete[]), they also construct (or
destruct) the array of objects. The second versions are basically
concerned with just low-level allocation and deallocation.

2) If the second one is somehow a different delete[], will it act like:
operator delete[] (*p)
{
arraySize = (((WORDSIZE *)p)[0])*sizeOf(Fred)
InternalDelete(p,arraySize);

}

Something like that, for an appropriately defined InternalDelete
function. It needs to free the memory allocated above by operator new[]
which was: WORDSIZE + n * sizeof( Fred).

-Mark

[yufufi]

Mark P wrote:

yufufi wrote:

>mlimber wrote:

>>On Feb 20, 2:38 pm, yufufi <yufufi_at_comcast.netwrote:
How does delete[] know how much memory to deallocate from the given
pointer? AFAIK this informations is put there by new[]. new[] puts the
size of the allocated memory before the just before the beginning of
the
array. But I couldn't find this information by looking at the memory.
(Via VS2005 - C++)

http://www.parashift.com/c++-faq-lit...html#faq-16.14

My second questions is, if there is a mechanism to know how much memory
is allocated for the array, why don't we use it for things like bstr?
Only thing I can think of is you may go and allocate a big chunk of
memory with new[] and use it for more then one bstr's and such.
(However
i'm not even sure how you can do it with bstr since you have to use
::SysAllocString)

This part is off-topic here. Try a Microsoft group (cf. the list at
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9)

Cheers! --M

The page you point to answers the question of "How many objects to
destruct?" which is a little bit different then what I'm asking.

In the sample code for one of the delete[] implementations:

You're confused. This is not a delete[] implementation-- this is a
new[] implementation. The call to operator delete[] is in a catch block
which is there to prevent a memory leak in case one of the constructor
"calls" to Fred (via placement new) fails.

>>
// Original code: Fred* p = new Fred[n];
char* tmp = (char*) operator new[] (WORDSIZE + n * sizeof(Fred));
Fred* p = (Fred*) (tmp + WORDSIZE);
*(size_t*)tmp = n;
size_t i;
try {
for (i = 0; i < n; ++i)
new(p + i) Fred(); // Placement new
}
catch (...) {
while (i-- != 0)
(p + i)->~Fred(); // Explicit call to the destructor
operator delete[] ((char*)p - WORDSIZE);
throw;
}

'n' used to decide number of destructor calls needed. But in the line
one before the last:

operator delete[] ((char*)p - WORDSIZE);

Still compiler is presented with a pointer to an array(which in it's
first WORDSIZE has n)

1) Isn't this an infinite loop(recursive)?

No. As I already said, this is an implementation of new[] not of
delete[]. More to the point of your question, there's a distinction
between new[] and operator new[], and likewise for delete[] and operator
delete[]. The first versions not only allocate (or deallocate) memory
via operator new[] (or operator delete[]), they also construct (or
destruct) the array of objects. The second versions are basically
concerned with just low-level allocation and deallocation.

> 2) If the second one is somehow a different delete[], will it act
like:
operator delete[] (*p)
{
arraySize = (((WORDSIZE *)p)[0])*sizeOf(Fred)
InternalDelete(p,arraySize);
}

Something like that, for an appropriately defined InternalDelete
function. It needs to free the memory allocated above by operator new[]
which was: WORDSIZE + n * sizeof( Fred).

-Mark

Ok, my mistake I pasted the wrong code sample. Here is the correct one.

definition of operator delete[]:

size_t n = * (size_t*) ((char*)p - WORDSIZE);
while (n-- != 0)
(p + n)->~Fred();
operator delete[] ((char*)p - WORDSIZE);

Same questions apply here
1) isn't this recursive?
I guess you answer this one with the difference of 'operator new[]'
and 'new[]' Ok then am I allowed to call the second, low level
new/delete, which don't care about constr/destr but just memory
allocation? Why not use malloc/free instead of these?
2) how does the last delete[] know about the size?
3) How does free (for malloc) know how much memory to free starting
from the pointed memory location. It doesn't have constructor/destructor
mechanism so it doesn't need to put 'n' before the allocated array
memory. I guess answer to this would be also an answer to 2. (guessing
that new[] is actually malloc+constructors and delete[] is free+destructors)

Thank you,

yufufi

[Alf P. Steinbach]

* yufufi:

>
definition of operator delete[]:

No, this isn't a definition of operator delete[].

You're quoting the FAQ item "How do compilers use "over-allocation" to
remember the number of elements in an allocated array?", currently
available at <url:
http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.7>.

That FAQ item describes the code thusly:

"Then the delete[] p statement becomes:"

A "delete[] p" statement is not a simple call to operator delete[].

This has been explained to you already in this thread, and furthermore
the FAQ item's code exemplifies just that (you should also take a look
at the next FAQ item for an alternative way this can be done by the
compiler).

size_t n = * (size_t*) ((char*)p - WORDSIZE);
while (n-- != 0)
(p + n)->~Fred();
operator delete[] ((char*)p - WORDSIZE);

Same questions apply here
1) isn't this recursive?

No. The last statement isn't a "delete[] p" statement. It's an
invocation of operator delete[]. operator delete[] is a simple
deallocation function. It would probably have been better if was named
e.g. "deallocateArray" instead of the confusing "operator delete[]", but
then we wouldn't have so much fun discussing C++.
[snip]

2) how does the last delete[] know about the size?

The FAQ item you were directed to, which led you to the above, answers
that. As an alternative to clicking willy-nilly on the links, why don't
you /read/ it instead? That would most certainly help you.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[yufufi]

Alf P. Steinbach wrote:

* yufufi:

>>
definition of operator delete[]:

No, this isn't a definition of operator delete[].

You're quoting the FAQ item "How do compilers use "over-allocation" to
remember the number of elements in an allocated array?", currently
available at <url:
http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.7>.

That FAQ item describes the code thusly:

"Then the delete[] p statement becomes:"

What I understand from 'becomes' is that when you debug into that
function call you'll see similar lines to these..

>
A "delete[] p" statement is not a simple call to operator delete[].

This has been explained to you already in this thread, and furthermore
the FAQ item's code exemplifies just that (you should also take a look
at the next FAQ item for an alternative way this can be done by the
compiler).

>size_t n = * (size_t*) ((char*)p - WORDSIZE);
while (n-- != 0)
(p + n)->~Fred();
operator delete[] ((char*)p - WORDSIZE);

Same questions apply here
1) isn't this recursive?

No. The last statement isn't a "delete[] p" statement. It's an
invocation of operator delete[]. operator delete[] is a simple
deallocation function. It would probably have been better if was named
e.g. "deallocateArray" instead of the confusing "operator delete[]", but
then we wouldn't have so much fun discussing C++.

How does 'operator delete[]/deallocateArray' know about the size of the
memory to free? You only give it a starting point(a pointer) but it
doesn't have any endpoints. Maybe it can use the 'n' but that doesn't
sound right.

Let's forget about delete[] and focus on free(*p) (i know it's for c
world but i have a point). Does malloc put any information to somewhere
so that free knows how much memory to free starting from p?

[snip]

> 2) how does the last delete[] know about the size?

The FAQ item you were directed to, which led you to the above, answers
that. As an alternative to clicking willy-nilly on the links, why don't
you /read/ it instead? That would most certainly help you.

FAQ item 38.7 or 38.8 don't answer my question. It answers the question
of "How many destructors to run?" Freeing up part is done in:
operator delete[] ((char*)p - WORDSIZE);
I'm asking what's going on behind the scenes when you execute this
statement.

Thank you,

yufufi

[Alf P. Steinbach]

* yufufi:

FAQ item 38.7 or 38.8 don't answer my question. It answers the question
of "How many destructors to run?" Freeing up part is done in:
operator delete[] ((char*)p - WORDSIZE);
I'm asking what's going on behind the scenes when you execute this
statement.

Very simple, the global "operator delete[]" function is called, and
deallocates the memory.

How does it know how much memory to deallocate?

Either directly, in /one of the same ways/ as a delete[]-statement knows
how many destructors to call (the FAQ illustrates two such ways), or by
leaving that to e.g. the OS allocator, which does the same. In practice
only the two ways outlined in the FAQ are used, namely overallocation
with prepended size, or associative array. In theory other ways could
be used, such as traversing a linked list of free blocks and ensuring
that an allocated block always has a free block on each side, but that
would just amount to a very inefficient associative collection.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mark P]

yufufi wrote:

Alf P. Steinbach wrote:

>* yufufi:

>>>
definition of operator delete[]:

No, this isn't a definition of operator delete[].

You're quoting the FAQ item "How do compilers use "over-allocation" to
remember the number of elements in an allocated array?", currently
available at <url:
http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.7>.
That FAQ item describes the code thusly:

"Then the delete[] p statement becomes:"

What I understand from 'becomes' is that when you debug into that
function call you'll see similar lines to these..

>>
A "delete[] p" statement is not a simple call to operator delete[].

This has been explained to you already in this thread, and furthermore
the FAQ item's code exemplifies just that (you should also take a look
at the next FAQ item for an alternative way this can be done by the
compiler).

>>size_t n = * (size_t*) ((char*)p - WORDSIZE);
while (n-- != 0)
(p + n)->~Fred();
operator delete[] ((char*)p - WORDSIZE);

Same questions apply here
1) isn't this recursive?

No. The last statement isn't a "delete[] p" statement. It's an
invocation of operator delete[]. operator delete[] is a simple
deallocation function. It would probably have been better if was
named e.g. "deallocateArray" instead of the confusing "operator
delete[]", but then we wouldn't have so much fun discussing C++.

How does 'operator delete[]/deallocateArray' know about the size of the
memory to free? You only give it a starting point(a pointer) but it
doesn't have any endpoints. Maybe it can use the 'n' but that doesn't
sound right.

Why not? Look at the code you posted. Given p, it steps back by
WORDSIZE and reads the value of n. What more information do you think
it should need?

>
Let's forget about delete[] and focus on free(*p) (i know it's for c
world but i have a point). Does malloc put any information to somewhere
so that free knows how much memory to free starting from p?

Probably. This is also implementation dependent so it can do whatever
it wants. But it has to *work* and so, yes, it probably records this
information somewhere.

-Mark

[yufufi]

Mark P wrote:

yufufi wrote:

>Alf P. Steinbach wrote:

>>* yufufi:

definition of operator delete[]:

No, this isn't a definition of operator delete[].

You're quoting the FAQ item "How do compilers use "over-allocation"
to remember the number of elements in an allocated array?", currently
available at <url:
http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.7>.
That FAQ item describes the code thusly:

"Then the delete[] p statement becomes:"

What I understand from 'becomes' is that when you debug into that
function call you'll see similar lines to these..

>>>
A "delete[] p" statement is not a simple call to operator delete[].

This has been explained to you already in this thread, and
furthermore the FAQ item's code exemplifies just that (you should
also take a look at the next FAQ item for an alternative way this can
be done by the compiler).
size_t n = * (size_t*) ((char*)p - WORDSIZE);
while (n-- != 0)
(p + n)->~Fred();
operator delete[] ((char*)p - WORDSIZE);

Same questions apply here
1) isn't this recursive?

No. The last statement isn't a "delete[] p" statement. It's an
invocation of operator delete[]. operator delete[] is a simple
deallocation function. It would probably have been better if was
named e.g. "deallocateArray" instead of the confusing "operator
delete[]", but then we wouldn't have so much fun discussing C++.

How does 'operator delete[]/deallocateArray' know about the size of
the memory to free? You only give it a starting point(a pointer) but
it doesn't have any endpoints. Maybe it can use the 'n' but that
doesn't sound right.

Why not? Look at the code you posted. Given p, it steps back by
WORDSIZE and reads the value of n. What more information do you think
it should need?

That information is useful for the number of destructors to call not for
the amount of memory to free. Sure you can do n*sizeof(Fred), but last
call to operator delete[] doesn't know about 'Fred'. You only pass the
address not the Type as well.

>>
Let's forget about delete[] and focus on free(*p) (i know it's for c
world but i have a point). Does malloc put any information to
somewhere so that free knows how much memory to free starting from p?

Probably. This is also implementation dependent so it can do whatever
it wants. But it has to *work* and so, yes, it probably records this
information somewhere.

I'm trying to figure out where does it record this information.. Just
for 'Fun' purposes.

Thank you very much,

yufufi

[yufufi]

Alf P. Steinbach wrote:

* yufufi:

>FAQ item 38.7 or 38.8 don't answer my question. It answers the
question of "How many destructors to run?" Freeing up part is done in:
operator delete[] ((char*)p - WORDSIZE);
I'm asking what's going on behind the scenes when you execute this
statement.

Very simple, the global "operator delete[]" function is called, and
deallocates the memory.

How does it know how much memory to deallocate?

Either directly, in /one of the same ways/ as a delete[]-statement knows
how many destructors to call (the FAQ illustrates two such ways), or by
leaving that to e.g. the OS allocator, which does the same. In practice
only the two ways outlined in the FAQ are used, namely overallocation
with prepended size, or associative array. In theory other ways could
be used, such as traversing a linked list of free blocks and ensuring
that an allocated block always has a free block on each side, but that
would just amount to a very inefficient associative collection.

So you are suggesting that we may have a memory like this for some
implementation:

[Size Of Array In Bytes][Number of Objects][Memory for the user]

When you call new[] it goes and calls operator new[] which somehow gets
the memory. And then it puts 'Size Of Array In Bytes' to the beginning
and returns it to the new[]. Then new puts 'Number of Objects' to the
beginning of that and then returns it to the user.

Thank you very much,

Furkan

[red floyd]

yufufi wrote:

Mark P wrote:

>Probably. This is also implementation dependent so it can do whatever
it wants. But it has to *work* and so, yes, it probably records this
information somewhere.

I'm trying to figure out where does it record this information.. Just
for 'Fun' purposes.

Repeat what mark wrote after me . This Is Implementation Dependent.

Some allocators may store the length. Others may not. I once wrote an
allocator that had an overhead of two bits per allocated block. That's
right, a total of two bits. Obviously it didn't store a length.

So for all intents and purposes you can call it "magic". For further
details, you need to ask in a group dedicated to your compiler and platform.

[Alan Johnson]

yufufi wrote:

Alf P. Steinbach wrote:

>* yufufi:

>>FAQ item 38.7 or 38.8 don't answer my question. It answers the
question of "How many destructors to run?" Freeing up part is done in:
operator delete[] ((char*)p - WORDSIZE);
I'm asking what's going on behind the scenes when you execute this
statement.

Very simple, the global "operator delete[]" function is called, and
deallocates the memory.

How does it know how much memory to deallocate?

Either directly, in /one of the same ways/ as a delete[]-statement
knows how many destructors to call (the FAQ illustrates two such
ways), or by leaving that to e.g. the OS allocator, which does the
same. In practice only the two ways outlined in the FAQ are used,
namely overallocation with prepended size, or associative array. In
theory other ways could be used, such as traversing a linked list of
free blocks and ensuring that an allocated block always has a free
block on each side, but that would just amount to a very inefficient
associative collection.

So you are suggesting that we may have a memory like this for some
implementation:

[Size Of Array In Bytes][Number of Objects][Memory for the user]

When you call new[] it goes and calls operator new[] which somehow gets
the memory. And then it puts 'Size Of Array In Bytes' to the beginning
and returns it to the new[]. Then new puts 'Number of Objects' to the
beginning of that and then returns it to the user.

Thank you very much,

Furkan

That would be a valid implementation. I would expect, where possible,
for the implementation to optimize away the "Number of Objects", though.
If you know the size in bytes, and you know the size of one object,
then you know the number of objects.

--
Alan Johnson