How does delete know how much to deallocate?

[binarybob0001]

The title is passically my question. How does delete [] p know how much memory to get rid of.

[ovidiucucu]

The title is passically my question. How does delete [] p know how much memory to get rid of.

Why do you need that as long as it does its job?

[Paul McKenzie]

The title is passically my question. How does delete [] p know how much memory to get rid of.

Depends on the implementation.

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

Regards,

Paul McKenzie

[binarybob0001]

Why do you need that as long as it does its job?

Why not know how it works? Aren't you curious?

[binarybob0001]

Thanks, I'm going to look at other articles on that site too. It has some interesting stuff.

[ovidiucucu]

Why not know how it works? Aren't you curious?

Yes of course. As long as it deserves wasted time, and/or I'm going to write a compiler.

[Hacker2]

ovidiucucu,

Just because you don't want to know,
doesn't mean someone else is wrong to be interested.

Or does it just mean you are embarrassed
because you don't know the answer?

[ovidiucucu]

ovidiucucu,

Just because you don't want to know,
doesn't mean someone else is wrong to be interested.

Arrogance is when you think you know better when you really don't.

No, no. I want to know. Please enlighten me!

[SuperKoko]

As you understood, it needs in some cases, to store the array size somewhere.
Note that this 'somewhere' is unspecified.
And it does not always need to store the array size.
It only needs to store the array size if:

• The objects stored in the array have non-trivial destructors (that is destructors containing code).
• Or operator new[] is user-defined and operator delete[] is user-defined, with the second argument.

I think that the "associative array" solution is not good, even if it is less sensitive to the bug of 'delete' on objects allocated with 'new[]'.
Because there is a better solution to avoid efficiently this bug:
Store 4 bytes containing a magic number identifying the type of a memory block: allocated with 'new' or allocated with 'new[]'.
So the compiler checks for this magic number when delete or delete[] is called, and outputs a runtime error message (at least for debug versions) if delete is called on a new[] block, or delete[] is called on a 'new' block.
In fact, the magic number can also identify already deleted block, and outputs runtime error messages.

If you overload operator new and operator new[], you can easily and efficiently detect memory leaks (incrementing/decrementing a global counter), and invalid delete or delete[] operations.
Moreover the "associative array" solution needs probably 8 or 12 bytes for each allocated block, vs 2 or 4 bytes for the "magic number" solution.

Why not know how it works? Aren't you curious?

I am curious, but of course you must absolutely avoid using unspecified things, since they may change from one compiler version to another. It is a programmation error to use something unspecified.
Maybe, being "innocent" (not knowing at all how things are implemented) may avoid using unspecified behaviors.
But on the other side, i suppose that the proportion of programmers using delete where delete[] should be used is greater in the class of programmers who don't know why there is two versions of 'new'.
For example, i never had bugs with new[]/delete, but i know much on how compilers implement or may implement things (i like thinking how an hypotetical compiler may implement something).
I also suppose that curiousity highly depends on individual.
It may be good for someone and bad for someone else.

[Hacker2]

Thank you SuperKoko for this answer

Generally, it is good to know in detail how things work.
For example, in CStrings, if you set
String1 = "text1";
String2 = String1;
String2 = "text2";

this sets String1 to "text2" also, because String2=String1 sets
the pointers to the same text, it does not copy the text.

So if you know this, all is OK, but if you don't, there will be bugs.

But it is also important, that once you know the internal
workings of something, that you should ONLY access it
using good programming practice, i.e. do not access the
internal workings directly.

For example, if you want to access a member of a a structure,
and you figure out that it is the 2nd byte in the structure,
you may try writing that byte directly.
This is fine until the next release of software changes that structure
and moves the byte somewhere else.

So it is good to know how things work, and it is also good to
know how to apply that knowledge wisely.

But how much is enough? That is your decision.
You might be interested in malloc, which can take you to
the differences between debug malloc and release malloc,
which can take you to heaps and the stack,
which can take you to memory fragmentation
which can take you to etc etc etc.

But if that's where you want to go, then by all means go there.
At some point you might say "OK, I've gone deep enough,
I will just assume that this is how it works, and it's OK
if don't dig down to the next level."

Or you might say "hey, now that I dug deep enough,
I just thought of a great new way to allocate memory"
or some inspiration like that.

So as the old saying goes
There are no stupid questions,
only stupid answers
and stupid answerers.

[ovidiucucu]

So as the old saying goes
There are no stupid questions,
only stupid answers
and stupid answerers.

Yep, indeed, there are no stupid questions, just if are repeated again and again despite the answers, may become let's say "annoying".

[Kanker Noob]

Why do we exist?

[Sef]

Why do we exist?

#include <iostream>

class CKankerNoob
{
public:
     ~CKankerNoob()
     {
          std::cout << "bye bye";
     }
};

int main()
{
     CKankerNoob You;
     return 0;
}

[Paul McKenzie]

Thank you SuperKoko for this answer

Generally, it is good to know in detail how things work.

Yes, it's OK to know things in detail, but in no means is it a requirement.

So if you know this, all is OK, but if you don't, there will be bugs.

How will there be bugs if you don't know the internals of CString? If you use the public interface correctly, it doesn't matter if you know what CString is doing internally. This is the general rule for any well-written class. You don't need to know the internals, just use the public interface.

For example, if you took a good C++ programmer who has never seen or used CString before, and gave them the help file for CString as to its usage, there is little, if any chance, of them introducing bugs in their code once they use CString. And no, you don't need to know that CString is reference counted. That is just good information, but it is by no means important in using it correctly.

But it is also important, that once you know the internal
workings of something, that you should ONLY access it
using good programming practice, i.e. do not access the
internal workings directly.

So why study the internals when the correct way to use a class is only through the public interface (or protected interface if deriving from a base class)? You do not need to know how things are working internally for you to use it. Do you need to know the internals of a car engine for you to learn to drive a car?

Regards,

Paul McKenzie

[Paul McKenzie]

And it does not always need to store the array size.
It only needs to store the array size if:[*] The objects stored in the array have non-trivial destructors (that is destructors containing code).

I believe the Solaris Sun compiler will get a memory leak if you allocated a trivial type with new[], and then use "delete" instead of "delete[]". So at least for that compiler, it does make a difference what form of "delete" is used, even if the type is int*, char *, etc.

Regards,

Paul McKenzie