Printable View
Hi, my question is what is wrong with this code?
I do not think if there is anything wrong here but the expert who posed this question thinks that there is definitely something conceptually wrong here?Code:class T;
int main(){
T *p = 0;
delete p;
}
The only things that I can think of are:
if = or delete are overriden
does an overriden p matter here?
I can't see anything wrong with it.
You're deleting a pointer to a incomplete type. That's undefined behaviour.
Given that the pointer is null, nothing will actually happen, but that doesn't change the fact that the program is invalid, and a compliant compiler might simply refuse to compile it.
That should at least generate a warning.
Only if you turn on some warnings. Too many people don't bother compiling with Warning Level 4 in MSVC++ or -Wall in gcc. :(Quote:
Originally Posted by Elysia
If the type (class T) isn't complete, it will not have the destructor or overridden operators called on the object [although, technically, it is probably not at all defined what happens in this case - but most compilers will just treat it as a non-class destruction, just like if you use new + delete to allocate and destroy a plain data struct].
Actually, assigning a pointer of a class doesn't allow for operator overrides, since you can't actually override based on "pointer to type X is assigned a value" - you can override "X is assigned a value" [assuming X isn't a basic type].
Whether delete is overridden or not, it should cope with a 0 delete without doing anything wrong, and it shouldn't make any difference to this code. Delete of "0" is a valid case and should be allowed to pass through without doing anything.
--
Mats
"Conceptually wrong" doesn't mean the code will generate an error. It means "WTF were you thinking writing that code?". Why would you call delete on a pointer to an object that you haven't defined completely? Or that you know to be null?
True indeed. But then most examples provided in class, at job interviews, discussion forums, etc, are usually "distilled down" so that the code is very specifically doing what it needs to show a concept, but nothing beyond that. I take the above code as such - no, it's not something you would ever actually write, but throw in a few if's, for/while-loops and some "real code" in the middle - where some of those conditions may mean that the code passes all the way through without modifying p, and we have a real world scenario where this would happen.Quote:
Originally Posted by King Mir
--
Mats
By the way, I'm wondering if the original poster's "expert" is confusing delete with free - it is NOT valid to call free with a NULL value - it will attempt to free address zero, with usually immediate dire consequences.
--
Mats
It is perfectly valid to call free() with a null pointer, and the result is exactly the same as deleting a null pointer. See the specification of free(), 7.20.3.2/2 in the C99 standard. See also the specification of free() in the Single Unix Specification.Quote:
Originally Posted by matsp
Maybe it's not valid in C90.
The single biggest problem I can see is that you are implicitly creating the p object on the stack, and deleting it from the heap.
I don't know if it's simply my memory, but I'm 100% sure I've had problems trying to free a NULL-pointer. It may of course be pre-C90 even, since I generally try not to even get to the free when the pointer is NULL.Quote:
Originally Posted by CornedBee
I had a quick look at google "man free" before I posted, the place I found didn't say anything [either direction] about using free with a NULL pointer, so I assumed that this was still a problem.
--
Mats
How's the above different from this:Quote:
Originally Posted by abachler
The above code will definitely run and perform correctly. I guarantee it.Code:int main(int argc, char **argv[])
{
int *p = 0;
if (argc > 1)
p = new int;
delete p;
return 0;
}
--
Mats
I think that the C++ Standard guarantees it too, but only if you actually declare the command line arguments or otherwise declare argc. If not, argc does not exist, so you make a poor guarantor.Quote:
The above code will definitely run and perform correctly. I guarantee it.
Perfectly valid in the spec maybe, but this is one of those cases where you can't really rely on the spec. Using C++ delete on a null pointer is safe, but calling C free() on a NULL pointer crashes on about half the machines I have access to, specifications notwithstanding.Quote:
Originally Posted by CornedBee
Some older (prestandard) implementations of the C library were associated with a free() function that would produce unexpected behaviour - often a crash - when supplied with a NULL pointer.Quote:
Originally Posted by brewbuck
While, theoretically, the standard eliminated this, the situation of a free() function crashing on NULL was quite common practically. This situation continued for several years after the standard, as a flaw in several mainstream compilers/libraries because it was easy to work around and therefore not a high priority fix for compiler/library vendors. It also affected some older (eg during and before the period when the C++ standard was in draft) C++ implementations in which new/delete operators employed malloc()/free() behind the scenes.
Much as idealists will insist otherwise, not every developer has the luxury of upgrading their compilers and libraries to the latest and greatest. The result is that, practically, those who care about portability of code will often avoid calling free() or invoking operator delete with a NULL pointer.