Caveat: this is a hard problem, and if you're not familiar with how and when DESTROY gets invoked and does its work, the above advice probably just gives you rope to hang yourself with.

GL,

I'm wondering whether the object isn't being constructed and blessed in C++ using XS. If that's the case then I guess I could see how this might be happening. I still really want to see the code to understand what kind of brokenness is occurring here.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

1) we use SWIG, not XS
   the C++ object is a PERL HASH
   i can invokes methods on the object with
        OBJ->method()
   just like a PERL object!   :-)
[download]


exactly what code do you want to see?
i sort of feel that this is a "philosophical" issue and not a "coding" mistake
in another reply, i pointed out that OUR works.
based on my limited understanding of OUR;
it seems that OUR prevents PERL from deleting the C++ Object when its being passed around.
but the OUR declaration has to be global

i have a perl HASH which is a SWIG wrapper of a C++ object.

if i new the object, and pass the reference around
it sometimes works and sometimes fails.


if NEW is in MAIN and passed "down", it works
if NEW is in ROUTINE and passed "up", it fails
[download]


and hopefully my usage of up/down is clear!
using namespaces :

if new'd as 
MAIN::object,          -> works in all "lower" routines
if new'd as 
MAIN::routineA::object -> does NOT work in MAIN
[download]


you have a interesting point about newSVsv. it looks like i want something like that.
i need a mechanism for PERL to never delete an object
but i wanted to avoid using a GLOBAL variable that is OUR
maybe that is the purpose of OUR?

I have to say, I'm very confused by your capitalization. Perl is case-sensitive. There is no OUR, there is only our. Similarly, when you refer to MAIN, I don't know whether you're referring to the default main namespace in Perl, or something having to do with C++ or SWIG.

I can understand your English despite the miscapitalization of words like "I". However, your Perl/C++ leaves me baffled. Can you please reformulate this message to use proper capitalization and punctuation in both the English and the code?

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com

A typical strategy is to package your C or C++ thing as a pointer and then make an object out of it. The key here is that perl objects are references so the thing they're pointing to is present as long as the object is. You really ought to post some of your code if you want better help.

i didn't post code because i don't think it's a problem where one can point at a line and say AHA!
the SWIG module is simply :

sub method {
    my @args = @_;
    $args[0] = tied(%{$args[0]});
    my $result = C++CODE::method(@args);
    return $result;
}
[download]

and perl grabs the package with

use lib (<path>)
use (C++ package)
[download]


as one would expect


my $dsgn = new (c++_object)
$dsgn->(method)
[download]


and these lines work IF done in MAIN. if done in a routine and returned to MAIN; it dumps core.
the object is a PERL HASH; and the address never changes when printed out. at first, i thought that meant the object is still present; but the C++ folks say otherwise.
i'm thinking it's a namespace issue. another perl coder has declared the object as a global OUR. that seems to work only for the case :

MAIN
my C++object
  C++object = pckA::routine
  pckB::routine(C++object)

PACKAGEA
our C++object
  routine
      new C++object
      return C++object

PACKAGEB
  routine
      my $C++object = @_
      $C++object->method()
[download]


and it ONLY works with OUR! so why is the OUR declaration required? is it a PERL problem with swigged objects or is the C++ code not swig/perl compatable?

if done in a routine and returned to MAIN; it dumps core

So the following would dump core:

my $dsgn = create_new();
$dsgn->(method);

sub create_new {
    my $ret = new (c++_object);
    return $ret;
}
[download]

I wonder what would happen if the reference count were incremented before returning:

my $dsgn = create_new();
$dsgn->(method);

sub create_new {
    my $ret = new (c++_object);
    refcnt_inc($ret);
    return $ret;
}
[download]

I don't think there exists a perl function/module that implements a reference count increment - in which case you'd need to do it with Inline::C/XS/SWIG. (I guess SWIG can help out there ... I know nothing about it.) Even if incrementing the reference count does work, that doesn't guarantee that it's the most appropriate thing to do.

A simple little Inline::C script that increments the reference count:

use warnings;
use Inline C => Config =>
    BUILD_NOISY => 1;

use Inline C => <<'EOC';

void refcnt_inc(SV * sv) {
     SvREFCNT_inc(sv);
}

SV * get_refcnt(SV * sv) {
    return newSVuv(SvREFCNT(sv));
}

EOC

$x = 1;
print get_refcnt($x), "\n";
refcnt_inc($x);
print get_refcnt($x), "\n";
[download]


Not sure if there's anything in this post that helps .... :-)

Cheers,
Rob

but routines can call other routines, without first returning to MAIN, true?


MAIN
  &routineA

ROUTINEA
  &routineB

ROUTINEB
  .....
[download]


so a flow that works is :

MAIN
  new C++object
  routineA(C++object)
  routineB(C++object)
[download]

but a flow that does NOT work is :

MAIN
  my C++object = routineA
  C++object->method
ROUTINEA
  my C++object = new C++design
  return C++object
[download]


yes, i agree with your last statement. ( that it is a C++ usage/style issue ) although we use SWIG, instead of XS.