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

You could do the double indirection thing.

That is, instead of passing the SV that wraps your C++ object to the Perl code, pass an SvRV that points to that SV. Then your Perl code would have to indirect through the SvRV to get at the object 

my $cppOref = shift;
return unless $$cppOref;

$$cppOref->whatever

[download]

That way, your C++ destructor can undef the SV, and any copies of the SvRV that the Perl code has retain will point to undef. It won't stop someone making a copy of the dereferenced SV: my $sneaky = $$cppOref; and falling in a heap by trying to use it later, but that's an education thing.

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.
RIP PCW It is as I've been saying!(Audio until 20090817)
  • Comment on Re: perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: perl embedded in C++: how to undefine perl objects that are blessed references to C++ objects when the C++ object destructs
by kingkongrevenge (Scribe) on Sep 19, 2009 at 15:49 UTC
    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.
[reply]

      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]

In Section Seekers of Perl Wisdom