The title is passically my question. How does delete [] p know how much memory to get rid of.
Printable View
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?Quote:
Originally Posted by binarybob0001
Depends on the implementation.Quote:
Originally Posted by binarybob0001
http://www.parashift.com/c++-faq-lit...html#faq-16.14
Regards,
Paul McKenzie
Why not know how it works? Aren't you curious?Quote:
Originally Posted by ovidiucucu
Thanks, I'm going to look at other articles on that site too. It has some interesting stuff.
Yes of course. As long as it deserves wasted time, and/or I'm going to write a compiler.Quote:
Originally Posted by binarybob0001
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?
No, no. I want to know. Please enlighten me!Quote:
Originally Posted by Hacker2
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.
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.Quote:
Originally Posted by binarybob0001
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.
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.
Yep, indeed, there are no stupid questions, just if are repeated again and again despite the answers, may become let's say "annoying".Quote:
Originally Posted by Hacker2
Why do we exist?
Quote:
Originally Posted by Kanker Noob
Code:#include <iostream>
class CKankerNoob
{
public:
~CKankerNoob()
{
std::cout << "bye bye";
}
};
int main()
{
CKankerNoob You;
return 0;
}
Yes, it's OK to know things in detail, but in no means is it a requirement.Quote:
Originally Posted by Hacker2
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.Quote:
So if you know this, all is OK, but if you don't, there will be bugs.
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.
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?Quote:
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.
Regards,
Paul McKenzie
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.Quote:
Originally Posted by SuperKoko
Regards,
Paul McKenzie
Hi
If one know the things in Detail one can use the things better way, efficiently and can avoid the probable BUG's.
As in CString eg. You can take the advantage of the explained behaviour, which might be possible by using public interfaces.
BECAUSE NOTHING IS IDEAL IN UNIVERSE
Thanks!
Anant
The universe is full of ideals. The problem is achieving... ;)Quote:
Originally Posted by anantwakode
Off topic ...apologies for that...but Ovidiu..Achieving comes later...the problem is realizing. this goes better...and a note - if you get annoyed by some repeated question..you might not want to reply to it..or just re-direct them to the previous thread where it was answered. Now since people usually make mistakes like this (not searching if their questions have been already answered..) and once they have done it...there is no way to undo this event. Just re-direct or answer or ignore (if it annoys anyone)...but to question someone's curiosity doesnt sound good to me. It sometimes de-motivates, which we would never (NEVER) intend to do. Cheers. :thumb:Quote:
Originally Posted by ovidiucucu
Thank you for the good, competent advices. I have printed them, hung on the wall, and further will be law for me. :D ;)Quote:
Originally Posted by exterminator
:wave:
Really? Then that would be an honor for me (since you are so..so..senior to me.. but if not :) .Quote:
Originally Posted by ovidiucucu
Okay now back to the topic of the thread. I saw the links pointed to by Paul. The parashift faq lite one. And in both the implementations I saw that placement new operator was being used. I had started a thread looking for possible usages of placement new and I didnt get this as an application.
Although, is this really true (in all cases..if not all ..most cases) that the new[] is implemented in terms of placement new? I would quote one of the methods' code here:Here, there is usage of 'operator new[]' and then there is the usage of placement new 'new(p + i) Fred()'. Now, as far as I know - the main objective of the placement new operator is to make a call to the corresposnding constructor once the memory allocations are done. My questions areCode:// 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;
}
1. Does the operator new[] not make a call to the corresponding constructor as well? If this is true...then I guess there would be 2 subsequent calls to the constructor .... which is wierd and highly undesirable and I am sure not even happening... ! If no then actually we are inside the definition of the operator and is there again some other definition of itself?
2. Is this operator new[] defined again somewhere and that too differently so as to ensure just the memory allocations (and no constructor calls?)?
3. Is this definition in some function? What would be the signature of that function? Does it somehow not indicate that the calls are becoming recursive? [I mean operator new[] being called from inside of the operator new[]'s definition]
4. Should there have been a malloc or something that only allocates memory instead of the operator new[]?
In simple words..I am consfused about this implementation. I understand the underlying concept and objective but not this implementation.. [Hope I explained my confusions/doubts clearly]