Hello friends....
can anyone tell me what will happen when we do..."delete this"...
31  8434 
* Anamika:
Hello friends....
can anyone tell me what will happen when we do..."delete this"...
The same as happens when you do "delete p" where p is a pointer.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Anamika wrote:
can anyone tell me what will happen when we do..."delete this"...
The object's destructor is going to be invoked and the pointer to
the current object will be used to free the memory.
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
On Apr 4, 6:24 pm, "Alf P. Steinbach" <a...@start.nowrote:
* Anamika:
Hello friends....
can anyone tell me what will happen when we do..."delete this"...
The same as happens when you do "delete p" where p is a pointer.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
no will it give any error message? or it will act madly?
Anamika wrote:
On Apr 4, 6:24 pm, "Alf P. Steinbach" <a...@start.nowrote:
>* Anamika:
>>Hello friends....
can anyone tell me what will happen when we do..."delete this"...
The same as happens when you do "delete p" where p is a pointer.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
no will it give any error message? or it will act madly?
Does a regular "delete p" do all that?
Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.
However, what does the C++ standard say?
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:ev**********@news.datemas.de...
Anamika wrote:
>On Apr 4, 6:24 pm, "Alf P. Steinbach" <a...@start.nowrote:
>>* Anamika:
Hello friends....
can anyone tell me what will happen when we do..."delete this"...
The same as happens when you do "delete p" where p is a pointer.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
no will it give any error message? or it will act madly?
Does a regular "delete p" do all that?
No, but it's not necessarily executed within the object being
deleted. The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so. Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
P.J. Plauger wrote:
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:ev**********@news.datemas.de...
>Anamika wrote:
>>On Apr 4, 6:24 pm, "Alf P. Steinbach" <a...@start.nowrote:
* Anamika:
Hello friends....
can anyone tell me what will happen when we do..."delete this"...
The same as happens when you do "delete p" where p is a pointer.
--
A: Because it messes up the order in which people normally read
text. Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
no will it give any error message? or it will act madly?
Does a regular "delete p" do all that?
No, but it's not necessarily executed within the object being
deleted. The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so. Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.
Thanks. That confirms that my first answer to the OP was correct.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Juha Nieminen wrote:
Victor Bazarov wrote:
>If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.
Correct, unless it's a virtual function.
However, what does the C++ standard say?
Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?
On 4 Apr 2007 06:22:37 -0700, "Anamika" <sh*************@gmail.comwrote:
>Hello friends....
can anyone tell me what will happen when we do..."delete this"...
Same as regular delete. Member variables (and most likely virtual functions
too, as the vtable pointer would likely not be available) will no longer be
available after the statement. But other than that, business as usual.
-dr
Victor Bazarov wrote:
Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?
That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).
I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?
Juha Nieminen wrote:
Victor Bazarov wrote:
>Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?
That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).
I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?
Assume nothing. Essentially, one needs to get out of that member
function as soon as possible. Basically the safest assumption (if
you just have to assume something) is that any call to any member
functions or use of any data member has undefined behaviour.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Victor Bazarov wrote:
Juha Nieminen wrote:
Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed? A non-static member function gets a pointer to the
object passed in to it, said pointer now deleted. I think just that use
of the pointer as a function argument causes UB.
Brian
Default User wrote:
Victor Bazarov wrote:
>Juha Nieminen wrote:
>>Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed?
Possibly not. We're talking "from a technical point of view".
A non-static member function gets a pointer to the
object passed in to it, said pointer now deleted. I think just that
use of the pointer as a function argument causes UB.
There was a discussion (or several) on what constitues "use". I have
heard/read that there even existed the architecture in which it was
possible to get a hardware exception if a register would contain
an invalid pointer. When in doubt, check.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Default User wrote:
Victor Bazarov wrote:
>Juha Nieminen wrote:
Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed?
No.
A non-static member function gets a pointer to the object passed in to it,
said pointer now deleted. I think just that use of the pointer as a
function argument causes UB.
How member functions are implemented by the compiler doesn't matter. Calling
a non-static member function of a deleted object invokes undefined behavor.
The standard explicitly says that.
Rolf Magnus wrote:
Default User wrote:
Victor Bazarov wrote:
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed?
No.
I wouldn't have thought so, but didn't have time to go through the
standard.
A non-static member function gets a pointer to the object passed in
to it, said pointer now deleted. I think just that use of the
pointer as a
function argument causes UB.
How member functions are implemented by the compiler doesn't matter.
Calling a non-static member function of a deleted object invokes
undefined behavor. The standard explicitly says that.
That's plenty good enough.
Brian
In article <46***********************@news.song.fi>,
Juha Nieminen <no****@thanks.invalidwrote:
>Victor Bazarov wrote:
>Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?
That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).
I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?
Do you mean it should say so explicitly? It doesn't need to.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
On Apr 4, 4:12 pm, "P.J. Plauger" <p...@dinkumware.comwrote:
"Victor Bazarov" <v.Abaza...@comAcast.netwrote in message
news:ev**********@news.datemas.de...
On Apr 4, 6:24 pm, "Alf P. Steinbach" <a...@start.nowrote:
* Anamika:
>>Hello friends....
can anyone tell me what will happen when we do..."delete this"...
>The same as happens when you do "delete p" where p is a pointer.
no will it give any error message? or it will act madly?
Does a regular "delete p" do all that?
No, but it's not necessarily executed within the object being
deleted.
Not necessarily, but code which tries to avoid delete this often
ends up doing it in a function called from within the object,
which amounts to the same thing.
The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so.
Which is true for delete p as well. Anytime you delete
something, don't use any pointer to the deleted object. The
this pointer isn't special in this regards.
The one thing you might be concerned about is that when you do
"delete this", you know that there is at least one pointer to
the object still floating around; the one which whoever called
you has. In my experience, however, there are almost always
more than one pointer to the object floating around, regardless
of who does the delete, and that you have to design to take this
into account, and ensure that these other pointers are
eliminated. (The observer pattern is very useful here.) So
"delete this" doesn't really change anything in this regard
either.
Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.
In fact, the "delete this" should be the last thing you do in
the function, period (except maybe for any logging saying that
you're leaving the function). Again, it's more or less the same
rule I use for "delete p"---That line should be the last line in
the scope in which p is defined.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Apr 4, 4:11 pm, Juha Nieminen <nos...@thanks.invalidwrote:
Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.
However, what does the C++ standard say?
It says it's OK, as long as no non-static member is accessed.
Calling a member function (even a non-virtual one) is undefined
behavior, and of course, any access to a non-static data member
is undefined behavior.
In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Apr 4, 6:32 pm, Juha Nieminen <nos...@thanks.invalidwrote:
Victor Bazarov wrote:
Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?
That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).
I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?
Well, it certainly doesn't say that: if it did, I'd put all the
entire application in one function which did "delete this" at
the top, and never have to debug again:-).
But you're right to ask: an implementation might conceivably
store the return address in the object, or some silliness like
that. In fact, the standard does set up a set of very specific
rules. As long as you obey those rules, an implementation is
required to make your code work. Since there is nothing in the
rules which says you cannot "delete this", it is OK, as long as
you obey the rest of the rules. (One of those rules say, for
example, that you cannot even read the this pointer without
incurring undefined behavior. Also, you cannot access any
non-static member, including calling a non-static function,
since this involves reading the this pointer.)
The issue was discussed before the standard was adopted, and the
concensus was that "delete this" is legal. (There's even an
example where the code explicitly calls this->~C(). Not quite
"delete this", but most of the same issues apply.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Victor Bazarov wrote:
Default User wrote:
>Victor Bazarov wrote:
>>Juha Nieminen wrote:
Victor Bazarov wrote:
If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed?
Possibly not. We're talking "from a technical point of view".
That's what _you_ are talking about. The question was: "However, what does
the C++ standard say?"
Rolf Magnus wrote:
Victor Bazarov wrote:
>Default User wrote:
>>Victor Bazarov wrote:
Juha Nieminen wrote:
Victor Bazarov wrote:
>If the object wasn't allocated using 'new', the behaviour is
>undefined. If any of object's data members or virtual functions
>are accessed after 'delete this', the behaviour is undefined.
>
From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member
variable of the object is accessed.
Correct, unless it's a virtual function.
Is that guaranteed?
Possibly not. We're talking "from a technical point of view".
That's what _you_ are talking about. The question was: "However, what
does the C++ standard say?"
Yes, Rolf. And I answered it already: "nothing special". Anything
else you need to clarify?
Victor Bazarov wrote:
Rolf Magnus wrote:
>Victor Bazarov wrote:
>>Default User wrote:
Victor Bazarov wrote:
Juha Nieminen wrote:
>Victor Bazarov wrote:
>>If the object wasn't allocated using 'new', the behaviour is
>>undefined. If any of object's data members or virtual functions
>>are accessed after 'delete this', the behaviour is undefined.
>>
>From a technical point of view it's not dangerous to execute code
>of a member function of a deleted object as long as no member
>variable of the object is accessed.
>
Correct, unless it's a virtual function.
Is that guaranteed?
Possibly not. We're talking "from a technical point of view".
That's what _you_ are talking about. The question was: "However, what
does the C++ standard say?"
Yes, Rolf. And I answered it already: "nothing special".
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".
Anything else you need to clarify?
No, that would be all.
James Kanze wrote:
[..]
In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
Whatever is done after that should be very well documented to
[try to] prevent somebody from adding something with undefined
behaviour to it.
(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
On Apr 6, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
[..]
In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
Whatever is done after that should be very well documented to
[try to] prevent somebody from adding something with undefined
behaviour to it.
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.
(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
That's not always practical. What is better by far is setting
the deleted pointer to 0 right after deletion.
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.
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On Apr 6, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>James Kanze wrote:
>>[..]
In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
>Whatever is done after that should be very well documented to
[try to] prevent somebody from adding something with undefined
behaviour to it.
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.
>>(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
>That's not always practical. What is better by far is setting
the deleted pointer to 0 right after deletion.
That's typically wasted effort, since the actual pointer is
immediately going out of scope.
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.
The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
Not sure what you mean.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
In article <ev**********@news.datemas.de>,
Victor Bazarov <v.********@comAcast.netwrote:
>James Kanze wrote:
>On Apr 6, 2:54 am, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>>James Kanze wrote:
[..]
In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
>>Whatever is done after that should be very well documented to
[try to] prevent somebody from adding something with undefined
behaviour to it.
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.
>>>(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
>>That's not always practical. What is better by far is setting
the deleted pointer to 0 right after deletion.
That's typically wasted effort, since the actual pointer is
immediately going out of scope.
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.
> The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
Not sure what you mean.
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.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau wrote:
In article <ev**********@news.datemas.de>,
Victor Bazarov <v.********@comAcast.netwrote:
>James Kanze wrote:
>> The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
Not sure what you mean.
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.
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.
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.
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
In article <ev**********@news.datemas.de>,
Victor Bazarov <v.********@comAcast.netwrote:
>Greg Comeau wrote:
>In article <ev**********@news.datemas.de>,
Victor Bazarov <v.********@comAcast.netwrote:
>>James Kanze wrote:
The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
Not sure what you mean.
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.
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.
>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.
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.
I meant the latter, but now that you mention it: both :)
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Dnia Fri, 06 Apr 2007 01:45:22 -0700, James Kanze napisa³(a):
The presence of "delete this" in the code should be
documentation enough.
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.
--
SasQ
On Apr 6, 2:10 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
James Kanze wrote:
>(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)
That's not always practical. What is better by far is setting
the deleted pointer to 0 right after deletion.
That's typically wasted effort, since the actual pointer is
immediately going out of scope.
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.
In that case, certainly, but I wouldn't call that typical.
Think list, tree, any other hierarchical dynamic structure.
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.
We've gone off the original subject a bit here, though.
The problem (whether "delete
this" or "delete p") is always the other pointers to the object.
Not sure what you mean.
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.
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Apr 6, 8:51 pm, SasQ <s...@go2.plwrote:
Dnia Fri, 06 Apr 2007 01:45:22 -0700, James Kanze napisa³(a):
The presence of "delete this" in the code should be
documentation enough.
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.
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.
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.
If the method call 'delete this' inside, the
valid pointer turns to invalid discretely.
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.)
--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: foo |
last post by:
I'm creating a debug class called debug_mem_allocation for the purpose
of finding memory leaks.
I used macro's to replace the new and delete operators.
My problem is with trying to replace the...
|
by: Roy Smith |
last post by:
I understand that "delete xp" deletes a scalar object and "delete xp"
deletes an array of objects, but what I don't understand is why you need
to tell the compiler which you're doing.
When you...
|
by: Amy |
last post by:
Hello,
We are developing C++ appplications for PDAs where memory is limited,
so we want to do memory management by ourselves --- pre-allocated a big
chunk and overwrite new and delete to call...
|
by: mandatory |
last post by:
hi,
i have a pointer to a class, which is dynamically allocated with new.
myClass *mC = new myClass();
What if i at a later point in my code i have this:
void *pointer;
|
by: John Baker |
last post by:
Hi:
Access 2000 W98!
I have a table with numerous records in it, and am attempting to delete certain records
that have been selected from it. These are selected based on the ID number in a...
| | |
by: silver360 |
last post by:
Hello,
I'm trying to create a basic Heap manager and i have some question
about new/delete overloading.
The following code give me this output :
>> $./heap
>> registered : 0x804d098
>>...
|
by: junw2000 |
last post by:
Hi,
Below is a small code about memory allocation and deallocation.
#include <cstdlib>
#include <iostream>
using namespace std;
class X {
public:
void* operator new(size_t sz) throw (const...
|
by: junw2000 |
last post by:
I use the code below to study delete and destructor.
#include <iostream>
using namespace std;
struct A {
virtual ~A() { cout << "~A()" << endl; }; //LINE1
void operator delete(void* p) {...
|
by: rohits123 |
last post by:
I have an overload delete operator as below
//////////////////////////////////
void operator delete(void* mem,int head_type) {
mmHead local_Head = CPRMemory::GetMemoryHead(head_type);...
|
by: =?Utf-8?B?R2Vvcmdl?= |
last post by:
Hello everyone,
I remembered delete is implemented through operator overloading, but I am
not quite clear.
Could anyone recommend some links about how delete is implemented so that
I can...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
