NAME

SYNOPSIS

    use Inline CPP;

    print "9 + 16 = ", add(9, 16), "\n";
    print "9 - 16 = ", subtract(9, 16), "\n";

    __END__
    __CPP__

    int add(int x, int y) {
      return x + y;
    }

    int subtract(int x, int y) {
      return x - y;
    }

DESCRIPTION

RATIONALE

Inline::CPP is about that critical 3%.

Tom "Duff's Device" Duff once wrote the following: "The alternative to genuflecting before the god of code-bumming is finding a better algorithm... ...If your code is too slow, you must make it faster. If no better algorithm is available, you must trim cycles."

Often, well written Perl is fast enough. But when one comes across a situation where performance isn't fast enough, and no better algorithm exists, getting closer to the metal is one way to trim cycles, assuming it's done well. Inline::CPP minimizes the pain in binding C++ code to Perl via XS.

Performance can also be evaluated in terms of memory requirements. Perlish datastructures are beautifully simple to use, and quite powerful. But this beauty and power comes at the cost of memory and speed. If you are finding that it is too memory-expensive to hold your data in a Perl array, and a disk-based solution is, for whatever reason, not an option, the memory burden can be aleviated to some degree by holding the data in a C++ data type.

This can only go so far. But the common saying is that if you consider a reasonable amount of memory to hold a data structure, double it, and then multiply by ten, you'll have a pretty good feel for how much memory Perl needs to hold it. Inline::CPP can facilitate a leaner alternative.

"The standard library saves programmers from having to reinvent the wheel." -- Bjarne Stroustrup

Inline::CPP is also about not reinventing the wheel.

There are many C and C++ libraries already in existence that provide functionality that is well tested, well debuged, and well understood. There is often no great benefit aside from portability in rewriting such libraries in pure Perl. Even re-writing them in XS is cumbersome and prone to bugs. Inline::CPP can be used to quickly develop Perl bindings to existing C++ libraries.

"Brian Ingerson got fed up with writing XS and ended up writing a very clever Perl module called Inline to do it for him."

Face it, XS has a big fat learning curve, lots of boilerplate, and is easy to botch it up in difficult to find ways. Inline::CPP exists to make that process easier. By lightening the cognative load and boilerplate drudgery associated with pure XS, Inline::CPP can aid the developer in producing less buggy extension code. It won't shield you entirely from "perlguts", but it will take the edge off of it.

Choosing a C++ Compiler

If you're one of the fortunate majority, you will accept the defaults as you install Inline::CPP; the correct C++ compiler and standard libraries will be configured for you. If you're one of the unfortunate (and shrinking) minority, read on.

Here's the rule: use a C++ compiler that's compatible with the compiler which built "perl". For instance, if "perl" was built with "gcc", use "g++". If you're on a Sun or an IRIX box and the system C compiler "cc" built "perl", then use the system C++ compiler, "CC".

Some compilers actually compile both C and C++ with the same compiler. Microsoft's "cl.exe" is one such compiler -- you pass it the <-TP> flag to convince it that you want C++ mode. Hopefully this will be deduced by default at install time.

If you're using the GNU C++ compiler, make sure that you have the g++ front end installed (some Linux distros don't install it by default, but provide it via their package management utilities).

Using Inline::CPP

This module uses a grammar to parse your C++ code, and binds to functions or classes which are recognized. If a function is recognized, it will be available from Perl space. If the function's signature is not recognized, it will not be available from Perl, but will be available from other functions or classes within the C++ code.

The following example shows how C++ snippets map to Perl:

Example 1:

    use Inline CPP => <<'END';

    using namespace std;

    int doodle() { }

    class Foo {
     public:
       Foo();
       ~Foo();

       int get_data() { return data; }
       void set_data(int a) { data = a; }
     private:
       int data;
    };

    Foo::Foo() { cout << "creating a Foo()" << endl; }
    Foo::~Foo() { cout << "deleting a Foo()" << endl; }

    END

After running the code above, your Perl runtime would look similar to if following code had been run:

    sub main::doodle { }

    package main::Foo;

    sub new { print "creating a Foo()\n"; bless {}, shift }
    sub DESTROY { print "deleting a Foo()\n" }

    sub get_data { my $o=shift; $o->{data} }
    sub set_data { my $o=shift; $o->{data} = shift }

The difference, of course, is that in the latter, Perl does the work. In the Inline::CPP example, all function calls get sent off to your C++ code. That means that things like this won't work:

    my $obj = new Foo;
    $obj->{extrafield} = 10;

It doesn't work because $obj is not a blessed hash. It's a blessed reference to a C++ object.

C++ Compilation Phase

Where to put C++ code

    use Inline CPP => 'DATA';

    # Perl code here

    __DATA__
    __CPP__

    // C++ code here.

Or....

    use Inline CPP => <<'END_CPP';
        // C++ code here.
    END_CPP

Structurally where does it belong? For simple one-off scripts, just put it anywhere you want. But in the spirit of code reusability, it's often better to simply create a module that houses the functionality build upon C++ code:

    # Foo/Bar.pm
    package Foo::Bar;
    use Inline CPP => 'DATA';

    # Perl code here, including Exporter mantra, if needed.

    __DATA__
    __CPP__
    // C++ here.....

Where you place your module's file(s) follows the same rules as plain old Perl, which is beyond the scope of this POD, but fortunatly no different from what you're used to (assuming you're used to writing Perl modules).

Of course, modules can be shared by multiple scripts while only incurring that compilation startup penalty one time, ever.

Basing (CPAN) Distributions on Inline::CPP

An example and proof-of-concept for this approach can be found in the CPAN module Math::Prime::FastSieve.

This approach involves using Inline::MakeMaker, and is well documented in the Inline POD under the heading Writing Modules with Inline <http://search.cpan.org/perldoc?Inline#Writing_Modules_with_Inline>

However, you may wish to remove the Inline::CPP dependency altogether from the code that you bundle into a distribution. This can be done using InlineX::CPP2XS, which converts the Inline::CPP generated code to Perl XS code, fit for distribution without the Inline::CPP dependency. InlineX::CPP2XS includes an example/ directory that actually converts Math::Prime::FastSieve to pure XS.

Some extension authors choose to implement first in Inline::CPP, and then manually tweak, then copy and paste the resulting XS file into their own distribution, with similar effect (and possibly a little finer-grained control) to the CPP2XS approach.

    package Some::Foo;
    use Inline CPP => <<'END_CPP';

    #include <iostream>
    using namespace std;

    class Foo {
      private:
        int data;
      public:
        Foo()  { cout << "creating a Foo()" << endl; }
        ~Foo() { cout << "deleting a Foo()" << endl; }
    };

    END_CPP
    1;

    use Inline CPP => config => namespace => 'Some';

C++ Configuration Options

All configuration options, including the word "config" are case insensitive. "CPP", and "DATA" are not configuration options, and are not insensitive to case.

    use Inline CPP => config => altlibs => '-L/my/other/lib -lfoo';

    use Inline CPP => config => auto_include => '#include "something.h"';

    use Inline CPP => config => boot => 'foo();';

    use Inline CPP => config => cc => '/usr/bin/g++-4.6';

    use Inline CPP => config => ccflags => '-std=c++11';

    use Inline CPP => config =>
        classes => { 'CPPFoo' => 'PerlFoo', 'CPPBar' => 'PerlBar' };

    use Inline CPP => config =>
        namespace => 'Qux' =>
        classes => { 'CPPFoo' => 'PerlFoo', 'CPPBar' => 'PerlBar' };

    use Inline CPP => config =>
        classes => sub {
            my $cpp_class = shift;
            ...
            return($perl_package);
        };

    class MyClass {
      private:
        int a;
      public:
        MyClass() :a(10) {}
        int fetch () { return a; }
    };

    #include "/tmp/Foo__Bar__MyClass.c"
    class MyClass {
      private:
        int a;
      public:
        MyClass() :a(20) {}
        int fetch () { return a; }
        int other_fetch () { MyClass mybar; return mybar.fetch(); }
    };

    use Inline CPP => '/tmp/Foo__Qux__MyClass.c' => namespace => 'Foo::Qux';

    _08conflict_encounter_t_9d68.xs:25:7: error: redefinition of ‘class MyClass’
     class MyClass {
           ^
    In file included from _08conflict_encounter_t_9d68.xs:24:0:
    /tmp/Foo__Bar__MyClass.c:1:7: error: previous definition of ‘class MyClass’
     class MyClass {
           ^

    class Foo__Bar__MyClass {
      private:
        int a;
      public:
        Foo__Bar__MyClass() :a(10) {}
        int fetch () { return a; }
    };

    #include "/tmp/Foo__Bar__MyClass.c"
    class Foo__Qux__MyClass {
      private:
        int a;
      public:
        Foo__Qux__MyClass() :a(20) {}
        int fetch () { return a; }
        int other_fetch () { Foo__Bar__MyClass mybar; return mybar.fetch(); }
    };

    use Inline  CPP => '/tmp/Foo__Qux__MyClass.c' =>
                namespace => 'Foo' =>
                classes => { 'Foo__Bar__MyClass' => 'Bar::MyClass',
                             'Foo__Qux__MyClass' => 'Qux::MyClass' };

    use Inline CPP => config =>
        classes => sub { join('::', split('__', shift)); };

    use Inline CPP => config => filters => [Strip_POD => \&myfilter];
    use Inline CPP => config => filters => 'Preprocess';  # Inline::Filters

    use Inline CPP => config => inc => '-I/my/path';

    use Inline CPP => config => libs => '-L/your/path -lyourlib';

    use Inline CPP => config => libs => '-L/my/path', libs => '-lyourlib';

    use Inline CPP => config => myextlib => '/your/path/something.o';

    use Inline CPP => config => namespace => 'Foo';
    use Inline CPP => config => namespace => 'main';
    use Inline CPP => config => namespace => q{};

    package Foo;
    use Inline CPP => config => namespace => 'Bar';
    use Inline CPP => <<'EOCPP';

    class Baz {
      private:
        int a;
      public:
        Baz() :a(20) {}
        int fetch () { return a; }
    };
    EOCPP

    package main;
    my $b = Bar::Baz->new();
    print $b->fetch, "\n"; # 20.

    package Foo;
    use Inline CPP => <<'EOCPP';
    class Foo {
      private:
        int a;
      public:
        Baz() :a(20) {}
        int fetch () { return a; }
    };
    EOCPP

    package main;
    my $b = Foo::Foo->new();
    print $b->fetch, "\n"; # 20.

    package Foo;
    use Inline CPP => config => namespace => q{};  # Disassociate from
                                                   # calling package.
    use Inline CPP => <<'EOCPP';

    class Baz {
      private:
        int a;
      public:
        Baz() :a(20) {}
        int fetch () { return a; }
    };
    EOCPP

    package main;
    my $b = Foo->new();
    print $b->fetch, "\n"; # 20.

    use Inline CPP config => prefix => 'ZLIB_';

    use Inline CPP config => preserve_ellipsis => 1;
or
    use Inline CPP config => enable => 'preserve_ellipsis';

    use Inline CPP => config => enable => 'std_iostream';

    use Inline CPP config => structs => 'Foo';
or
    use Inline CPP config => structs => ['Bar', 'Baz'];

    use Inline CPP config => enable => 'structs';
or
    use Inline CPP config => structs => 1;

    use Inline CPP config => disable => 'structs';
or
    use Inline CPP config => structs => 0;

    use Inline CPP config => typemaps => '/your/path/typemap';

C++-Perl Bindings

Perl uses a stack to pass arguments back and forth to subroutines. When a sub is called, it pops off all its arguments from the stack; when it's done, it pushes its return values back onto the stack.

XS (Perl's language for creating C or C++ extensions for Perl) uses "typemaps" to turn SVs into C types and back again. This is done through various XS macro calls, casts, and the Perl API. XS also allows you to define your own mappings.

"Inline::CPP" uses a much simpler approach. It parses the system's typemap files and only binds to functions with supported types. You can tell "Inline::CPP" about custom typemap files too.

If you have non-trivial data structures in either C++ or Perl, you should probably just pass them as an SV* and do the conversion yourself in your C++ function.

In C++, a struct is a class whose default scope is public, not private. Inline::CPP binds to structs with this in mind -- get/set methods are not yet auto-generated (although this feature may be added to an upcoming release).

If you have a C struct, you can use Inline::Struct to allow Perl complete access to the internals of the struct. You can create and modify structs from inside Perl, as well as pass structs into C++ functions and return them from functions. Please note that Inline::Struct does not understand any C++ features, so constructors and member functions are not supported. See Inline::Struct for more details.

  TYPEMAP
  string  T_CPPSTRING

  INPUT

  T_CPPSTRING
          $var = ($type)SvPV_nolen($arg)

  OUTPUT

  T_CPPSTRING
          sv_setpv((SV*)$arg, $var.c_str());

  use Inline CPP => config => typemaps => "typemap";
  use Inline CPP => <<'END';

  #ifdef __INLINE_CPP_STANDARD_HEADERS
  #include <string>
  #else
  #include <string.h>
  #endif

  #ifdef __INLINE_CPP_NAMESPACE_STD
  using namespace std;
  #endif

  class Abstract {
    public:
          virtual string greet2() {
              string retval = "yo";
              return retval;
          }
  };

  class Impl : public Abstract {
    public:
      Impl() {}
      ~Impl() {}
  };
  END

  my $o = Impl->new;
  print $o->greet2, "\n";

<iostream>, Standard Headers, C++ Namespaces, and Portability Solutions

ANSI Standard C++ changed that. Headers were renamed without the '.h' suffix, and standard tools were placed in the '"std"' namespace. The "using namespace std" and "using std::string" constructs were also added to facilitate working with namespaces.

So pre-Standard (Legacy) C++ code might look like this:

   #include <iostream.h>
   int main() {
       cout << "Hello world.\n";
       return 0;
   }

Modern "ANSI Standard C++" compilers would require code like this:

   #include <iostream>
   using namespace std;
   int main() {
       cout << "Hello world.\n";
       return 0;
   }

... or ...

   #include <iostream>
   int main() {
       std::cout << "Hello world.\n";
       return 0;
   }

... or even ...

   #include <iostream>
   int main() {
       using std::cout;
       cout << "Hello world.\n";
       return 0;
   }

The first snippet is going to be completely incompabible with the second, third or fourth snippets. This is no problem for a C++ developer who knows his target compiler. But Perl runs just about everywhere. If similar portability (including backward compatibility) is a design goal, Inline::CPP helps by providing two "#define" constants that may be checked to ascertain which style of headers are being used. The constants are:

   __INLINE_CPP_STANDARD_HEADERS
   __INLINE_CPP_NAMESPACE_STD

"__INLINE_CPP_STANDARD_HEADERS" will be defined if the target compiler accepts ANSI Standard headers, such as <iostream>. "__INLINE_CPP_NAMESPACE_STD" will be defined if the target compiler supports namespaces. Realistically the two are synonymous; ANSI Standard C++ uses namespaces, places standard library tools in the "std" namespace, and invokes headers with the modern (no '.h' suffix) naming convention. So if one is defined they both should be.

They can be used as follows:

    use Inline CPP => 'DATA';

    greet();

    __DATA__
    __CPP__

    #ifdef __INLINE_CPP_STANDARD_HEADERS
    #include <string>
    #else
    #include <string.h>
    #endif

    #ifdef __INLINE_CPP_NAMESPACE_STD
    using namespace std;
    #endif

    void greet() {
        string mygreeting = "Hello world!\n";
        cout << mygreeting;
    }

You may decide that you don't care about maintaining portability with compilers that lock you in to pre-Standadr C++ -- more than a decade behind us. But if you do care (maybe you're basing a CPAN module on Inline::CPP), use these preprocessor definitions as a tool in building a widely portable solution.

If you wish, you may "#undef" either of those defs. The definitions are defined before any "auto_include"s -- even <iostream>. Consequently, you may even list "#undef __INLINE_CPP_...." within an "auto_include" configuration directive. I'm not sure why it would be necessary, but could be useful in testing.

Regardless of the header type, Inline::CPP will create the following definition in all code it generates:

    #define __INLINE_CPP 1

This can be useful in constructing preprocessor logic that behaves differently under Inline::CPP than under a non-Inline::CPP environment.

EXAMPLES

   use Inline CPP;

   my $farmer = new Farmer("Ingy", 42);
   my $slavedriver = 1;
   while($farmer->how_tired < 420) {
     $farmer->do_chores($slavedriver);
     $slavedriver <<= 1;
   }

   print "Wow! The farmer worked ", $farmer->how_long, " hours!\n";

   __END__
   __CPP__

   class Farmer {
   public:
     Farmer(char *name, int age);
     ~Farmer();

     int how_tired() { return tiredness; }
     int how_long() { return howlong; }
     void do_chores(int howlong);

   private:
     char *name;
     int age;
     int tiredness;
     int howlong;
   };

   Farmer::Farmer(char *name, int age) {
     this->name = strdup(name);
     this->age = age;
     tiredness = 0;
     howlong = 0;
   }

   Farmer::~Farmer() {
     free(name);
   }

   void Farmer::do_chores(int hl) {
     howlong += hl;
     tiredness += (age * hl);
   }

   use Inline 'CPP';

   my $plane = new Airplane;
   $plane->print;
   if ($plane->isa("Object")) { print "Plane is an Object!\n"; }
   unless ($plane->can("fly")) { print "This plane sucks!\n"; }

   __END__
   __CPP__

   using namespace std;

   /* Abstract class (interface) */
   class Object {
   public:
     virtual void print() { cout << "Object (" << this << ")" << endl; }
     virtual void info() = 0;
     virtual bool isa(char *klass) = 0;
     virtual bool can(char *method) = 0;
   };

   class Airplane : public Object {
   public:
     Airplane() {}
     ~Airplane() {}

     virtual void info() { print(); }
     virtual bool isa(char *klass) { return strcmp(klass, "Object")==0; }
     virtual bool can(char *method) {
       bool yes = false;
       yes |= strcmp(method, "print")==0;
       yes |= strcmp(method, "info")==0;
       yes |= strcmp(method, "isa")==0;
       yes |= strcmp(method, "can")==0;
       return yes;
     }
   };

   sub average {
      my $average = 0;
      for (my $i=0; $i<@_; $i++) {
         $average *= $i;
         $average += $_[$i];
         $average /= $i + 1;
      }
      return $average;
   }

   double average() {
      Inline_Stack_Vars;
      double avg = 0.0;
      for (int i=0; i<Inline_Stack_Items; i++) {
         avg *= i;
         avg += SvNV(Inline_Stack_Item(i));
         avg /= i + 1;
      }
      return avg;
   }

    use Inline 'CPP';
    my @numbers = map { rand } (1 .. 10000);
    my ($a, $stop);
    $stop = 200;
    if (@ARGV) {
      $a = avg(@numbers) while $stop--;
    }
    else {
      $a = average(@numbers) while $stop--;
    }
    print "The average of 10000 random numbers is: ", $a, "\n";

    sub average {
       my $average = 0;
       for (my $i=0; $i<@_; $i++) {
           $average *= $i;
           $average += $_[$i];
           $average /= $i + 1;
       }
       return $average;
    }

    __END__
    __CPP__

    double avg(...) {
       Inline_Stack_Vars;
       double avg = 0.0;
       for (int i=0; i<items; i++) {
           avg *= i;
           avg += SvNV(ST(i));
           avg /= i + 1;
       }
       return avg;
    }

    double avg(...)

    double avg(   )

    void myprintf(char *format, ...);

    use Inline 'CPP';

    my $q = new Queue;
    $q->q(50);
    $q->q("Where am I?");
    $q->q("In a queue.");
    print "There are ", $q->size, " items in the queue\n";
    while($q->size) {
        print "About to dequeue:  ", $q->peek, "\n";
        print "Actually dequeued: ", $q->dq, "\n";
    }

    my $s = new Stack;
    $s->push(42);
    $s->push("What?");
    print "There are ", $s->size, " items on the stack\n";
    while($s->size) {
        print "About to pop:    ", $s->peek, "\n";
        print "Actually popped: ", $s->pop, "\n";
    }

    __END__
    __CPP__

    class Queue {
      public:
        Queue(int sz=0) { q = newAV(); if (sz) av_extend(q, sz-1); }
        ~Queue() { av_undef(q); }

        int size() {return av_len(q) + 1; }

        int q(SV *item) { av_push(q, SvREFCNT_inc(item)); return av_len(q)+1; }
        SV *dq() { return av_shift(q); }
        SV *peek() { return size() ? SvREFCNT_inc(*av_fetch(q,0,0)): &PL_sv_undef;}

      private:
        AV *q;
    };

    class Stack {
      public:
        Stack(int sz=0) { s = newAV(); if (sz) av_extend(s, sz-1); }
        ~Stack() { av_undef(s); }

        int size() { return av_len(s) + 1; }

        int push(SV *i) { av_push(s, SvREFCNT_inc(i)); return av_len(s)+1; }
        SV *pop() { return av_pop(s); }
        SV *peek() { return size() ? SvREFCNT_inc(*av_fetch(s,size()-1,0)) : &PL_sv_undef; }

      private:
        AV *s;
    };

    use Inline CPP => 'DATA';

    say multiadd( 1 );          # No dispatch; just return the value.
    say multiadd( 1, 2 );       # Dispatch add( int, int ).
    say multiadd( 1, 2, 3 );    # Dispatch add( int, int, int ).
    say multiadd( 1, 2, 3, 4 ); # No dispatch; throw an exception.
    __DATA__
    __CPP__

    #include <stdexcept>

    // Inline::CPP won't create predictable bindings to overloaded functions.

    int add ( int a, int b ) {
      return a + b;
    }

    int add ( int a, int b, int c ) {
      return a + b + c;
    }

    // But a function call with elipses can dispatch to overloaded functions since
    // no Perl binding is required in reaching those functions.
    int multiadd ( SV * a, ... ) {
      dXSARGS;  // Creates a variable 'items' that contains a paramater count.
      try{
        switch ( items ) {
          case 1:  return SvIV(ST(0));
          case 2:  return add( SvIV(ST(0)), SvIV(ST(1)) );
          case 3:  return add( SvIV(ST(0)), SvIV(ST(1)), SvIV(ST(2)) );
          default: throw std::runtime_error(
            "multiadd() - Too many args in function call"
          );
        }
      }
      catch ( std::runtime_error msg ) {
        croak( msg.what() );  // Perl likes croak for exceptions.
      }
    }

Minimum Perl version requirements

C++11 Standard

Taking the first question first (because it's the easiest): Use the "ccflags" option shown above to pass the proper flag to your compiler to enable C++11 features. Most of what your compiler will support, "Inline::CPP" will deal with.

You also may need to use the "cc" flag to specify a newer version of the compiler, if you happen to have more than one installed -- one that handles C++11 and one that doesn't.

Now for the question of what Perl needs to care about: Inline::CPP doesn't look inside of functions or methods. That code is treated as a black box that passes directly through to your compiler. So inside of your functions and methods, feel free to use whatever C++11 features you want.

The critical areas are function headers, class definitions, and code that falls outside of functions or classes. Take Enums for example:

    enum Colors { RED, GREEN, BLUE };

How should this map to Perl? There's no clear answer. C++11 adds the concept of scope to enums:

    enum class Colors { RED, GREEN, BLUE };

How this should bind to Perl becomes even more difficult. The fact is that Inline::CPP won't bind either to Perl. And you're probably better off with that approach than suddenly having $Colors::RED = 0; showing up in your Perl code. Do keep in mind, however, the construct is passed directly through to your C++ compiler, so feel free to use it within the C++ code. It just won't leak out into your Perl namespaces.

At the moment the most glaring omission from Inline::CPP of valid C++11 syntax is the new "late return type" syntax. C++11 introduced the following legal syntax:

    auto add ( int x, int y ) -> int { return x + y; }

This omission is only going to be a factor for functions that you want to bind to Perl. If you don't need the function to bind to Perl, the syntax is fine; Inline::CPP just ignores the function. It's important to note that the most common uses of this syntax involve templates and lambdas. Templates don't make sense to Inline::CPP anyway. And lambdas are still fine, because they take place inside of functions, so Inline::CPP doesn't see them anyway. For now, just don't use the late return type syntax in the header of functions that need to bind to Perl. This may get fixed in future revisions to the grammar.

Another issue is "constexpr":

    constexpr int multiply ( int x, int y ) { return x * y; }

"constexpr" isn't recognized by Inline::CPP, so this function won't bind to Perl. I don't think that "constexpr" functions can even generate external bindings, because they're resolved to a constant at compile-time. They really don't make sense for external use (the compiler can't know how you will call them). Consequently, they'll be ignored by Inline::CPP (and will pass through to your compiler, so they will work within your C++ code).

And finally, Rvalue references:

Inline::CPP doesn't (yet) understand this:

    int x = 100;

    int getInt ()
    {
        return x;
    }

    int && getRvalueInt ()
    {
        return std::move( x );
    }

The "getInt()" function will bind to Perl, but the "&&" syntax isn't recognized by Inline::CPP, and won't result in a binding being generated. So "getRvalueInt()" will be invisible to Perl. However, it is perfectly legal to use within your C++ code as long as you don't need it to bind to Perl.

Aside from that (as far as I know), you're good to go! Go ahead and use the new version of "for( auto it: x ) {...}", or even...

    for_each( v.begin(), v.end(), [] (int val) { std::cout << val; } );

The beauty of Inline::CPP is that what goes on inside the black boxes of functions or methods is irrelevant to the binding process. These examples will "just work", assuming your C++ compiler understands them.

BUGS AND DEFICIENCIES

When reporting a bug, please do the following:

 - If possible, create a brief stand-alone snippet of code that
   demonstrates the issue.
 - Use  L<Github Issues|https://github.com/daoswald/Inline-CPP/issues> to file
   your bug report.
 - Patches are always welcome, as are tests that tickle a newfound bug.

 - Pull requests should avoid touching irrelevant sections of code/POD, and
   tests are required before they can be considered for merge.

...or...

 - Put "use Inline REPORTBUG;" at the top of your code, or
   use the command line option "perl -MInline=REPORTBUG ...".
 - Run your code.
 - Follow the printed instructions.

Get involved! Module development is being tracked on a github repository: <https://github.com/daoswald/Inline-CPP>.

The master branch should always be buildable and usable.

Official releases have version numbers in the following format: 'x.xx', and are usually tagged with the CPAN release number.

Various development branches will hold a combination of minor commits and CPAN "Developer" releases (these may have a version number formatted as: 'x.xx_xxx' to designate a developer-only CPAN release).

Most discussion relating to this module (user or developer) occurs on the Inline mailing list, inline.perl.org, and in "#inline" on "irc.perl.org". See <http://lists.perl.org/list/inline.html> for details on subscribing.

Here are some things to watch out for:

The grammar used for parsing C++ is still quite simple, and does not allow several features of C++:

Templates: You may use template libraries in your code, but Inline::CPP won't know how to parse and bind template definitions. The core problem is that the C++ compiler has no idea how a dynamic language like Perl intends to invoke template-generated code, and thus, cannot know what code to generate from the templates. Keep the templates encapsulated away from the interface that will be exposed to Perl by wrapping calls in functions that will give the compiler a type to work with.

Operator overloading

Function overloading -- This is a similar issue to the template problem. Perl doesn't know about C++'s function overload resolution rules. And C++ doesn't know about Perl. XS was never designed to deal with this sort of mismatch. This prevents implementing the Rule of Three for code that is intended to bind with Perl, but because Perl handles your bindings, that's probably not an issue.

These three issues (Templates, Operator Overloading, and Function Overloading) are situations where the C++ language and the Perl language simply do not map well to one another. The sooner you get used to this disconnect, the sooner you'll get a feel for what is going to work and what isn't. Templates are how a static language like C++ deals with the concept of generic programming. Perl is such a dynamic language, that templates (which are resolved entirely at compile time) cannot be resolved when called by Perl. Perl's concept of parameter passing is so dynamic that function signatures (which C++ uses in resolving overloads) also can't be mapped meaningfully. There will be other features of C++ don't map into Perl, and vice versa. Consider C++ enums. Should Perl treat them as constants by mapping them via the constant pragma? The answer is unclear, and the fact is they won't be bound into Perl at all.

Multiple inheritance doesn't work right (yet).

Multi-dimensional arrays as member data aren't implemented (yet).

Declaring a paramater type of void isn't implemented. Just use "int myfunc();" instead of "int myfunc(void);". This is C++, not C. It's ok, really.

Exceptions: While it's ok to throw an exception using 'throw', Perl won't know how to recover from it, and you'll get a core-dump instead of a Perlish death. The solution is simple, "croak("Message")". Perl will treat that as a call to "die". The fifth example above demonstrates how to get the best of both worlds: C++'s rich exception handling, and Perl's "die".

The gist of it is this: Catch your throws. And anything that can't be dealt with gracefully, re-throw back to Perl using "croak".

Other grammar problems will probably be discovered. This is Perl, C++, and XS all sealed into one can of worms. But it can be fun, which is a description never applicable to raw XS.

SEE ALSO

For information on using C with Perl, see Inline::C and Inline::C-Cookbook. For WMTYEWTK, see perlguts, perlxs, perlxstut, perlapi, and perlcall. The literature for Inline::C (including the cookbook) is relevant and useful in learning Inline::CPP too; just about everything that works for Inline::C will work for Inline::CPP. Rather than reiterate all those great examples here, it's better to just refer the reader to Inline::C and Inline::C-Cookbook's documentation.

For converting an Inline::CPP module to pure XS (for simpler distribution), see InlineX::CPP2XS. This method is usually preferable to distributing with an Inline::CPP dependency, however, if you want to do that, read on...

Math::Prime::FastSieve is a module based on Inline::CPP (using Inline::CPP and Inline::MakeMaker as dependencies). It serves as a proof of concept, another example of Inline::CPP at work, and a working example of basing a CPAN distribution on Inline::CPP.

User and development discussion for Inline modules, including Inline::CPP occurs on the inline.perl.org mailing list. See <http://lists.perl.org/list/inline.html> to learn how to subscribe.

The maintainer has found Advanced Perl Programming, 2nd Edition (O'Reilly) helpful, although its discussion is focused on Inline::C.

AUTHOR

David Oswald <DAVIDO@cpan.org> is the current maintainer. David Oswald's Inline::CPP GitHub repo is: <https://github.com/daoswald/Inline-CPP>

Ingy döt Net <INGY@cpan.org> is the author of "Inline", and "Inline::C".

CONTRIBUTING

Contributors may also fork the repo and issue a pull requests. Tests should accompany pull requests, and effort should be made to minimize the scope of any single pull request.

Pull requests should not add author names. Non-trivial contributions generally warrant attribution in the log maintained in the "Changes" file, though the decision to do at the discretion of the maintainers.

Please refer to the Artistic 2.0 license, contained in the "LICENSE" file, included with this distribution for further explanation.

LICENSE AND COPYRIGHT

All Rights Reserved. This module is free software, licensed under the Artistic license, version 2.0.

See http://www.perlfoundation.org/artistic_license_2_0