Do I have a memory leak here or not?
I saw this in real code, but I'm not sure of the comma operator here.Code:int *x = new int; delete x, x = 0;
I know its weird code and shouldnt be in production code but I'd still like to know
Do I have a memory leak here or not?
I saw this in real code, but I'm not sure of the comma operator here.Code:int *x = new int; delete x, x = 0;
I know its weird code and shouldnt be in production code but I'd still like to know
It's valid, and yes, it's weird.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That actually looks pretty handy. Although I'd take it a step further:Now you can debug double-check for invalid dereferences by putting in an if( x == NULL )throw e;Code:delete x, x = NULL
That's why Bjarne recommends that you create a safe_delete function that deletes the pointer and sets it to NULL:
http://www.research.att.com/~bs/bs_f...ml#delete-zeroCode:template<typename T> void SafeDelete(T& p) { delete p; p = NULL; } int main() { int* x = new int; SafeDelete(x); delete x; // Safe, because x is NULL. }
The net effect is the same, and in fact the code after preprocessing may even be exactly the same since NULL may be defined as 0.Originally Posted by @nthony
That's a paraphrase thoughOriginally Posted by Elysia
But it seems to me that Stroustrup's destroy() function template is a little more descriptive in its signature since it takes T*& instead of a T&, so it is more obvious that it works on pointers.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes, it may be more obvious, but it's also less flexible.
As long as a custom object has overloaded operator delete and and operator = (int), it can work with that function as well.
If you're going to make a generic function, you might as well go the whole way.
So you're sure that the comma operator doesnt change the line into "delete 0;"
because it takes the last expression as value?
I mean, in this expression
The result of scanf is discarded and only d != 0 gets evaluated.Code:while (scanf("%d", &d), d != 0)
Isn't that the same in delete x, x = 0? The x gets discarded and x is set to 0 and that gets passed to delete?
hmm... I am not convinced though: what does it mean to use destroy()/SafeDelete() on something other than a raw pointer? Also, wouldn't operator delete invoke the destructor, upon which the use of operator=(int) results in undefined behaviour?Originally Posted by Elysia
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
As far as I can tell, the comma operator has lower precedence than delete, so we are looking at:Originally Posted by KIBO
rather than:Code:(delete x), (x = 0);
Nonetheless, this potential confusion reinforces matsp's point.Code:delete (x, x = 0);
I do not think that it is harmful, just a little less descriptive in the function signature.Originally Posted by Elysia
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
That operator works on pointers to the object, not the object itself.As long as a custom object has overloaded operator delete
What you need is an unambiguous implicit conversion to a pointer type.
Basically, it would be a bad idea for everything except a smart pointer (since it doesn't make sense to delete anything besides a smart pointer) and it's a bad idea for smart pointers too, because the entire point of smart pointers is that you don't call delete yourself.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I would question, if x is deleted, why it remains in scope. Typically a pointer to a dynamically allocated object should go out of scope almost immediately after it is deleted.
In fact, this binding of deletion with going-out-of-scope is exactly what a smart pointer does. Perhaps you should use one.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Using commas is a rough practice no matter how you slice it. It is not as widely accepted in common practice thus its not too weird to see a programmer dumbfounded when they are introduced into a block of code. Either way I see now huge problem just making something like that an entirely separate line.