Re: Never ever use a raw pointer when a smart pointer can do the
same job
* Noah Roberts:
Alf P. Steinbach wrote:
* Noah Roberts:
Alf P. Steinbach wrote:
* Noah Roberts:
James Kanze wrote:
I suspect that there's a typo in there somewhere---you *never*
use delete this in a constructor. For the rest, delete this
doesn't require more care than any other delete.
Oh really? Well, let's try out this code:
struct an_object
{
void f() { delete this; }
};
void some_function()
{
an_object x;
x.f();
}
I guess your point is that some more care is required for 'delete
this' than for 'delete that', namely, taking care not to access any
members afterwards, which can be more of a problem when one is
currently within a member routine.
However your example does not illustrate that, it only illustrates
the usual dangers of 'delete' that apply irrespective of the context.
One way to design the class so that it's more safe wrt. the usual
dangers is as follows:
class AnObject
{
protected:
virtual ~AnObject() {}
public:
void f() { delete this; }
};
void someFunc()
{
AnObject x; // Compilation error, must be new'ed.
x.f();
}
Which is of course exactly what I said was important to remember when
you did a "delete this" (I protected the constructor instead). You'd
better make sure nobody can create that object as a local stack item
if you're going to do that.
You'd better also make sure of that whenever you 'delete'. ;-)
Since when?
Always.
Don't ever 'delete' an object that hasn't been allocated by 'new'.
Any object you'd call delete upon can also be safely
created on the stack. I know that you know this difference so I have no
idea why you'd argue otherwise.
Really...since when had you better make sure no client can create
something on the stack if you've called delete on some instance of it
somewhere???
That's a different question. Here you're not talking about "that object" that
you're deleting, but other instances. It sounds confused to me.
An object that deletes itself is vastly different in this
regard.
That issue is simply not different for 'delete this' versus 'delete
that'.
It's way different. If your object does a "delete this" then any client
that wants to use that object on the stack is not allowed to. If you
don't document this, but instead advertise an interface that allows
it...you've just screwed yourself and any future person working on the
product.
Yes, it's a good idea to limit how self-deleting objects can be allocated, and
that's why I showed how to do that, upthread.
However, it's not the case that using the self-deleting object then requires
more care in that respect.
On the contrary, with the self-deleting object class that aspect has been dealt
with centrally, whereas with the non-self-deleting object class the client code
generally has to deal with it, separately, for each and every instance, hence
*more* care is needed for the general non-self-deleting object class.
A "delete that" object behaves like any other object and can be safely
created on the stack. A "delete this" object does not and had better
not be.
This is actually just getting into areas too stupid to talk about. I'm
sorry, normally I have a lot of respect for your opinions but not in
this case.
Yes, it's pretty simple, and I don't understand why you didn't just agree as
soon as James and I joined the discussion; after all, we're always right. ;-)
Cheers,
- Alf (tongue in cheek)