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