in reply to Re: perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs
in thread perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs

I'll probably end up doing that. But if it's possible to do what I originally described (reach into the interpreter and undefine now invalid SV*) I'd still like to pursue it.
  • Comment on Re^2: perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs

Replies are listed 'Best First'.
Re^3: perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs
by BrowserUk (Patriarch) on Sep 19, 2009 at 16:01 UTC

    I'm far from expert on Perl internals, but given the way Perl allocates it variables I think that this would necessitate scanning the entire stack and entire heap attempting to find values in memory locations that 'look like' the SV* in question. Besides being rather slow, it is fraught with dangers.

    What would you search for? How would you distinguish between four bytes that contain the address of your C++ object, and four bytes that contain a number that coincidentally matches the address of your C++ object?

    And what benefit would you get? If the Perl code is going to indirect through a retained SV* and so trap; if you set it to undef, it is still going to indirect through it and die anyway. It might be a less violent death, but there is still no way for the Perl code to reasonably continue.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      Follow Up: I changed the perl class interfaces to C++ objects to be blessed references TO an SV reference to the the object pointer. 
      ThePerlClass=(BlessedSvRef) -> UnblessedSvRef -> theCppObjPointer

      [download]

      I only had to add the extra layer of indirection in the typemap and everything continued to work.

      When the C++ destructor for the relevant object is called, it sets the one and only copy of UnblessedSvRef to null. Any copies of the perl object floating around now just point to undef, which fails with a fathomable explanation (and a catchable exception) rather than catastrophically. When the last BlessedSvRef goes out of scope the ref count of UnblessedSvRef goes to zero and it's destroyed.

      I overloaded the bool operator to test for undef in UnblessedSvRef.

      I also overloaded the dereference operator so it's impossible for the user to get to the underlying UnblessedSvRef and store a pointer that can end up invalid.

[reply]
[d/l]
[select]

        Thanks for the update. I wish more OPs would do this.

        What you're doing sounds intriguing, but I'm having trouble visualising it. I don't supppose you fancy posting it do you? Not the whole thing, just the (relavent parts of) the construictor and destructor would be most interesting.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom