Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15476 > unrolled thread

Is this ok to do?

Back to article view | Back to comp.lang.c++

Contents

  Is this ok to do? jt@toerring.de (Jens Thoms Toerring) - 2012-04-19 19:34 +0000
    Re: Is this ok to do? Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-04-19 22:01 +0200
      Re: Is this ok to do? jt@toerring.de (Jens Thoms Toerring) - 2012-04-19 20:21 +0000
        Re: Is this ok to do? Juha Nieminen <nospam@thanks.invalid> - 2012-04-20 06:17 +0000
          Re: Is this ok to do? Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-04-20 13:20 +0200
          Re: Is this ok to do? jt@toerring.de (Jens Thoms Toerring) - 2012-04-20 17:00 +0000

#15476 — Is this ok to do?

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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [next] | [standalone]

#15477

On 19.04.2012 21:34, Jens Thoms Toerring wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#15478

Marcel Müller <news.5.maazl@spamgourmet.com> wrote:
> On 19.04.2012 21:34, Jens Thoms Toerring wrote:
> > 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

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

                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15487

Jens Thoms Toerring <jt@toerring.de> wrote:
>> 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.

  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.)

[toc] | [prev] | [next] | [standalone]

#15491

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

[toc] | [prev] | [next] | [standalone]

#15496

Juha Nieminen <nospam@thanks.invalid> wrote:
> Jens Thoms Toerring <jt@toerring.de> wrote:
> >> 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.

>   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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web