R
Rolf Magnus
Victor said:
That's what _you_ are talking about. The question was: "However, what does
the C++ standard say?"
That's what _you_ are talking about. The question was: "However, what does
the C++ standard say?"
V
Victor Bazarov
Rolf said:
Yes, Rolf. And I answered it already: "nothing special". Anything
else you need to clarify?
R
Rolf Magnus
Victor said:
It says that calling a non-static member function of a deleted object is
undefined behavior. Not everyone might be able to deduce that from "nothing
special".
No, that would be all.
V
Victor Bazarov
James said:
Whatever is done after that should be very well documented to
[try to] prevent somebody from adding something with undefined
behaviour to it.
That's not always practical. What is better by far is setting
the deleted pointer to 0 right after deletion. Of course it's
not possible with 'this' (but would be lovely)...
V
J
James Kanze
The presence of "delete this" in the code should be
documentation enough. In functions which call this function,
too: hopefully, no one is doing maintenance on the code without
knowing what the function he is modifying is supposed to do.
That's typically wasted effort, since the actual pointer is
immediately going out of scope. The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
V
Victor Bazarov
James said:
Uh.. no. If my object contains a pointer to a dynamically allocated
object, and my object is going to survive much longer than the object
it allocated, it makes all the sense in the world to keep the pointer
null until next allocation is made. Think list, tree, any other
hierarchical dynamic structure.
We've gone off the original subject a bit here, though.
Not sure what you mean.
V
G
Greg Comeau
The problem is that it is often "hard" to chase exactly which
additional pointers "should" be zero'd although with the "obvious one."
This is not the same as using an invalid pointer later on, because,
among other reasons, it may not be hard to not use it at other points
in the life of the program.
Note: This is a very debatable conversation. I've never been
in one on this topic which everybody got swayed one way or the other,
although it led to some converts.
V
Victor Bazarov
Greg said:
Yes, I realise that setting a single pointer to null does not make
other copies of the same pointer null as well. If that's the point,
I get it. That's why I said that setting 'this' to null is not
viable but it would be nice if it were possible.
Are you calling "delete this" debatable or setting the pointer to
null debatable? I am not challenging either point of view, I am
just trying to clarify.
V
G
Greg Comeau
I meant the latter, but now that you mention it: both
S
SasQ
Dnia Fri, 06 Apr 2007 01:45:22 -0700, James Kanze napisa³(a):
Only if you have access to this code and can read it
If you've got only compiled module with *.h, you're in ass ;P
My 2 cents: it's possible to call 'delete this', but it's
a hidden nasty little bastard who might bite you the whole leg:
It's possible to keep track the code inside a method which
calls 'delete this', but the outer code could possibly even
not know if the pointer used to call that nasty method is
still valid. If the method call 'delete this' inside, the
valid pointer turns to invalid discretely.
Only if you have access to this code and can read it
If you've got only compiled module with *.h, you're in ass ;P
My 2 cents: it's possible to call 'delete this', but it's
a hidden nasty little bastard who might bite you the whole leg:
It's possible to keep track the code inside a method which
calls 'delete this', but the outer code could possibly even
not know if the pointer used to call that nasty method is
still valid. If the method call 'delete this' inside, the
valid pointer turns to invalid discretely.
J
James Kanze
In that case, certainly, but I wouldn't call that typical.
Hmmm. My pre-standard lists never had any null pointers (or
pointers to nothing) in them. Nor do my hash tables. But a
tree, yes. Although typically, the pointer won't be set
immediately to null, because there will first be some dynamic
rebalancing, and it is only after the rebalancing that we know
which pointers get set to null.
If I write "delete this", it is immediately obvious in the
function that you can no longer use this. If I write "delete
p", it is immediately obvious that you cannot use p. On the
other hand, if there are pointers to the object elsewhere, it
may not be very obvious, in the context where those pointers are
used, that they've just become invalid.
J
James Kanze
Only if you have access to this code and can read it
If you've got only compiled module with *.h, you're in ass ;P
If you're not in a member function, you don't have access to
this, so the question is moot.
Do you mean that you call functions without knowing what they
do (or what they are supposed to do)? If that's the case, you
don't need delete this to have problems.
In practice, there is a category of entity objects which manage
their own lifetime---in many applications, most, if not all,
entity objects, fall into that category. The object decides, as
a response to an external even, that it should be deleted. You
can always rewrite the code so that the actual call to delete is
outside a member function, but this just hides it more.
What makes you think that the pointer will still be around when
the function which does "delete this" returns. (Remember, the
destructor will be called before the member function will
return. And the destructor is responsible for notifying
everyone who has a pointer to the object---not just whoever just
called the function---that the object is no longer there.)