Thread: weird delete construction

It's valid, and yes, it's weird.

Originally Posted by C_ntua

So it deletes x and then assigns x to 0?

Yes, and if I code-reviewed that, I'd suggest splitting it: delete x; x = 0; on a line for each of those statements.

--
Mats

That actually looks pretty handy. Although I'd take it a step further:

Code:

delete x, x = NULL

Now you can debug double-check for invalid dereferences by putting in an if( x == NULL )throw e;

That's why Bjarne recommends that you create a safe_delete function that deletes the pointer and sets it to NULL:

Code:

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

http://www.research.att.com/~bs/bs_f...ml#delete-zero

Originally Posted by @nthony

Although I'd take it a step further:

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 Elysia

That's why Bjarne recommends that you create a safe_delete function that deletes the pointer and sets it to NULL:

That's a paraphrase though
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.

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.

Originally Posted by Elysia

As long as a custom object has overloaded operator delete and and operator = (int), it can work with that function as well.

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?

You're probably right. I wouldn't want to try it on a non-pointer, but there's no harm in using T& instead of T*&, or perhaps there is?

Originally Posted by KIBO

So you're sure that the comma operator doesnt change the line into "delete 0;"
because it takes the last expression as value?

As far as I can tell, the comma operator has lower precedence than delete, so we are looking at:

Code:

(delete x), (x = 0);

rather than:

Code:

delete (x, x = 0);

Nonetheless, this potential confusion reinforces matsp's point.

Originally Posted by Elysia

I wouldn't want to try it on a non-pointer, but there's no harm in using T& instead of T*&, or perhaps there is?

I do not think that it is harmful, just a little less descriptive in the function signature.

As long as a custom object has overloaded operator delete

That operator works on pointers to the object, not the object itself.

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.

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.