Mailing List Archive

Yesterday I posted the typemap that I use with C++ extensions. I've changed
the name of the map to "OB_OBJECT" (opaque blessed object) because the same
map can be used with C structs and other gizmos. I've also included
"O_OBJECT" (opaque object--doesn't care about blessedness).

------
OUTPUT
# The Perl object is blessed into 'CLASS', which should be a
# char* having the name of the package for the blessing.
OB_OBJECT
if( $var != NULL )
sv_setref_pv( $arg, CLASS, (void*)$var );
O_OBJECT
if( $var != NULL )
sv_setref_pv( $arg, Nullch, (void*)$var );
INPUT
OB_OBJECT
if( SvROK($arg) && sv_isobject($arg) && (SvTYPE(SvRV($arg)) == SVt_PVMG) )
$var = ($type)SvIV((SV*)SvRV( $arg ));
else{
warn( \"${Package}::$func_name() -- $var is not a blessed SV reference\" );
XSRETURN_UNDEF;
}
O_OBJECT
if( SvROK($arg) )
$var = ($type)SvIV((SV*)SvRV( $arg ));
else{
warn( \"${Package}::$func_name() -- $var is not an SV reference\" );
XSRETURN_UNDEF;
}
-----

The OB_OBJECT uses the 'CLASS' variable that xsubpp sets up for C++, and
that anyone can setup for a non-C++ XS constructor. It doesn't rely on
sv_isa. It does check that THIS is a blessed SV.

I'd like to see this in lib/ExtUtils/typemap. It would make the C++ section
of perlxs simpler--actually it would simplify a few other pieces of perlxs,
too. This typemap overcomes the list of problems which plague maps like
T_PTROBJ (always blesses into base class, uses sv_isa so cannot be
subclassed, mangles class name so constructor has to be in a different class
than the methods).

Opinions/feedback, anyone?

Dean