Is this ok to do?

[Jens Thoms Toerring]

Hi,

sorry for the stupid subject but I had no good idea how to
condense it into a few words.

I have a method in a class A that calls a method of another class
B that in turn deletes the instance of class A from which it was
called (the B instance "owns" the instance of A and created it
calling 'new'). This feels a bit wrong since when the call of B's
method returns the instance of A has already ceased to exist. Ok,
I don't do anything in that method of A anymore after the call of
the B method returns (no use of 'this' or anything else that would
use data of A) but it still looks a bit dicy to me. Am I too pa-
ranoid and this is quite fine or are there real issues with this?

Best regards, Jens

 

[Marcel Müller]

I have a method in a class A that calls a method of another class
B that in turn deletes the instance of class A from which it was
called (the B instance "owns" the instance of A and created it
calling 'new'). This feels a bit wrong since when the call of B's
method returns the instance of A has already ceased to exist.

Seek for "delete this", which is basically the same.

E.g.
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15


Marcel

 

[Jens Thoms Toerring]

Seek for "delete this", which is basically the same.

E.g.
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15

Thank you, that's reassuring, as far as I can see all the points
mentioned there seem to be satisfied.

Best regards, Jens

 

[Juha Nieminen]

Thank you, that's reassuring, as far as I can see all the points
mentioned there seem to be satisfied.

Personally, I would still try to avoid that kind of situation and try
to think of a better design. Even if it works, it makes understanding the
inter-class dependencies and the program flow more complicated. When
reading code, one doesn't expect that the underlying object pointed by
'this' will suddenly disappear. (Adding a comment saying so in each line
where this (might) happen is only slightly alleviating the problem, and
prone to be skipped.)

 

[Marcel Müller]

On 20.04.2012 08:17, Juha Nieminen wrote:
[delete this;]

Personally, I would still try to avoid that kind of situation and try
to think of a better design. Even if it works, it makes understanding the
inter-class dependencies and the program flow more complicated. When
reading code, one doesn't expect that the underlying object pointed by
'this' will suddenly disappear. (Adding a comment saying so in each line
where this (might) happen is only slightly alleviating the problem, and
prone to be skipped.)

You may be right, but for self-managing objects I did not find a better
solution so far.

Think of dialog backend classes. Closing the dialog will obviously make
the backend object orphaned. So it is straight forward to delete the
backend a last action. And if public references to the backend classes
are allowed then reference counting is a suitable solution. Of course,
decrementing my own reference counter might still invoke delete this.

Any other solution requires some kind of common, static instance manager
that keeps track of all objects and has some kind of garbage collection.
This instance managers almost always involve threading issues and
sometime initialization sequence problems. Personally I prefer that the
backend class for a certain dialog has a static factory to show the
dialog. It is up to the implementation whether this is a singleton or not.


Marcel

 

[Jens Thoms Toerring]

Personally, I would still try to avoid that kind of situation and try
to think of a better design. Even if it works, it makes understanding the
inter-class dependencies and the program flow more complicated. When
reading code, one doesn't expect that the underlying object pointed by
'this' will suddenly disappear. (Adding a comment saying so in each line
where this (might) happen is only slightly alleviating the problem, and
prone to be skipped.)

I agree, but in this case there are a lot of additional con-
straints (it's in a library that must also be usable from
Python via a wrapper and Python has no notion of const-ness
etc.) that I can't see any way to avoid that - the object
that basically commit suicide (in a some- what round-about
manner) is an "accessor" object for an internal object the
user of the library shouldn't have direct access to. And to
remove that interal object the accessor object must induce
it to vanish which in turn the deletes the accessor since it
then, of course, is invalid.
Best regards, Jens