Mailing List Archive: C++ Extensions: A T

It seems as though I might be the first (or one of them) to be writing a
C++ extension to Perl. In particular none of the predefined typemaps
quite worked for me.

(Feel free to let me know if I've taken the wrong path, am reinventing
the wheel, etc.) I am leaving the process of compilation of XSUBs in C,
and linking it with C++ functions declared with C linkage (that is,
using the 'extern "C"' declaration of C++). This necessitates an extra
C++ wrapper function with C linkage for every C++ method I want to
appear in Perl, but the arguments I am converting back and forth to Perl
require complex enough logic that a wrapper is usually justified in any
case.

The class Marpa appears to C as a struct, so the return of constructors
and the first argument on non-static methods is of the form "struct
Marpa *" in C. If one uses the T_PTROBJ typemap, as suggested in the
perlxs pod, the result is not quite right: constructors returned refs
which appear to be blessed into packages "struct MarpaPtr". I slightly
modified the typemap T_PTROBJ so it bless objects into the package
specified in the XS file rather than a new package created from the type
name of the corresponding C struct.

The result follows:

TYPEMAP
struct Marpa* T_CLASS
INPUT
T_CLASS
if (sv_isa($arg, \"$Package\")) {
IV tmp = SvIV((SV*)SvRV($arg));
$var = ($type) tmp;
}
else
croak(\"$var is not of type Marpa\")
OUTPUT
T_CLASS
sv_setref_pv($arg, \"$Package\", (void*)$var);

Should the T_CLASS typemap be added to the list of defaults? Or is
my way of interfacing C++ to Perl idiosyncratic?

Cheers!

Jeffrey Kegler, Algorists, Inc.
jeffrey@algorists.com, http://www.best.com/~jeffrey
743 East El Camino Real #338, Sunnyvale CA 94087

> > If one uses the T_PTROBJ typemap, as suggested in the
> > perlxs pod, the result is not quite right: constructors returned refs
> > which appear to be blessed into packages "struct MarpaPtr".
>
> I'd love to have xsubpp leave the PTR stuff alone. It's really a pain when
> it blesses the object into a class different than the one in which the
> methods are found. When I wrote that piece of the perlxs pod I had no idea
> what was involved.

I would suggest that section of the POD be deleted until the C++
extension support appears in a stable release. I am afraid I was
somewhat misled by it. Possible replace that secion with "C++
extensions will be supported soon, and have substantial support in
developmental releases. For more information contact X or follow list
Y."

> [ stuff omitted -- JK ]
> $CC = 'CC';
> WriteMakefile(
> 'NAME' => 'CookBook::Ex7',
> 'VERSION' => '0.1',
> 'LIBS' => [''], # e.g., '-lm'
> 'DEFINE' => '', # e.g., '-DHAVE_SOMETHING'
> 'INC' => '', # e.g., '-I/usr/include/other'
> 'CC' => $CC,
> 'LD' => '$(CC)',
> 'LINKTYPE' => 'static',
> 'TYPEMAPS' => ['../perlobject.map' ],
> );
> [ stuff omitted -- JK ]

Is CC the name of your C++ compiler? I didn't quite follow the above.
Also, what about including -lg++? In the MakeMaker I was running
the libraries were searched for in regular expressions, which choked
on the plus signs. Does one add -lg++ in the top level makefile?

Cheers!

Jeffrey Kegler, Algorists, Inc.
jeffrey@algorists.com, http://www.best.com/~jeffrey
743 East El Camino Real #338, Sunnyvale CA 94087