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:
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.
My argument is for the requirement of that care.
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.
And now you're agreeing with that, for the second time.
That's nice, but baffling.
However, it's not the case that using the self-deleting object then
requires more care in that respect.
You'd better protect against stack based creation or you're going to
have problems, period.
Here you're violently agreeing with what I wrote in the previous paragraph, for
the third time.
That's, well, even more baffling.
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.
My argument is that any object that deletes itself must be protected
against stack allocation. This can clearly be seen by, as you say,
moving upthread.
"Must" is too strong, IMHO, but otherwise the article where I showed how to do
that, upthread, showed how to do that, so to speak.
And as that article showed, for a self-deleting object the requirement of
dynamic allocation can easily be enforced centrally, whereas this is not so for
objects that are deleted by client code.
And so your "oh really" in response to James' "delete this doesn't require more
care than any other delete" is shown to be inappropriate in this regard: for a
properly designed 'delete this' class the usage requires less care, not more.
If you want to argue about something else then maybe
you should do so with *someone* else.
It seems you have you've lost the original context, your original claim. So I
reiterated it above. :-)
Cheers & hth.,
- Alf