Is this ok to do?

Discussion in 'C++' started by Jens Thoms Toerring, Apr 19, 2012.

  1. 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 ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Apr 19, 2012
    #1
    1. Advertising

  2. 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
    Marcel Müller, Apr 19, 2012
    #2
    1. Advertising

  3. Marcel Müller <> 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 ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Apr 19, 2012
    #3
  4. Jens Thoms Toerring <> 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.)
    Juha Nieminen, Apr 20, 2012
    #4
  5. 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
    Marcel Müller, Apr 20, 2012
    #5
  6. Juha Nieminen <> wrote:
    > Jens Thoms Toerring <> 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 ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Apr 20, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page