in reply to Writing XS frontends to C++ libraries.

On your first question, C++ libraries mangle function names to attach an encoding of their agrument types. In that way, overloaded functions can be distinguished. Run the nm utility on a C++ lib to see examples. The c++filt does demangling.

The MySet class or type is not known to Perl without a little work. You need to produce a typemap to show perl what it is. Perhaps including its header in your h2xs run will suffice.

After Compline,
Zaxo

  • Comment on Re: Writing XS frontends to C++ libraries.

Replies are listed 'Best First'.
Re: Re: Writing XS frontends to C++ libraries.
by kilinrax (Deacon) on Sep 11, 2002 at 19:49 UTC

    I'm still confused as to why there should be an ambiguity about this section of the XS file: 

    void
MySettings::set(const string &key, const string &value)

    [download]
    When the error produced by the code shows that we have what looks like a matching method: 
    MyModule.c:64: no matching function for call to `Mysettings::set (cons
+t string *, const string *)'
/usr/local/include/mysettings.h:66: candidates are: void Mysettings::s
+et(const string &, const string &)

    [download]
    Does XS not distinguish well between pointers and references?

    MySet does have a typemap entry, of type O_OBJECT. I'll admit my understanding of typemaps is basic; this is just taken from the combining C++ and Perl link above.

[reply]
[d/l]
[select]

      The code you posted should look like this: 

      void
MySettings::set(key, value)
    string *      key
    string *      value

      [download]
      You're right about the problems with references. Don't try to use '&' in the XS prototype -- it definitely does not mean the same as C++. Also remember that in XS a const object is different from non-const, so you need two typemap definitions if you want to handle const objects.

      In general, you should use non-const pointers to interface C++ with perl -- eventually perl is going to stuff your object into an int, so it can't be bigger than a pointer. Pointers are conceptually easier to store, and const is going to be casted away anyways. Do your typemaps all use pointers?

      If you want to interface perl with methods that take const or reference arguments, the easiest way is to write the XS prototype with non-const pointers and then call the method yourself in the CODE: section. Here's how you'd call MySettings::set(const string &key, const string &value) from XS: 

      void
MySettings::set(key, value)
    string *      key
    string *      value
    CODE:
        THIS->set(*key, *value);

      [download]
      Try perldoc perlxs for more on XS. If you stick to non-const pointers you'll be able to follow most of the examples designed for C.

[reply]
[d/l]
[select]

        Thanks, that's helped a lot :)
        Unfortunately, however, some of the methods return objects, rather than pointers to objects; or take arguments in the same way - so still give errors as above.

        Currently I have lines like these for each object in my typemap: 

        MySettings           O_OBJECT
MYSettings *         O_OBJECT

        [download]
        Which, looking at it, seems very wrong. IIrc, O_OBJECT is for pointers to objects, not objects. Is there an equivalent to O_OBJECT for objects themselves, or will this require a specialised typemap?

[reply]
[d/l]

In Section Seekers of Perl Wisdom