NAME

Inline::CPP - Write Perl subroutines and classes in C++.

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

The Inline::CPP module allows you to put C++ source code directly "inline" in a Perl script or module. You code classes or functions in C++, and you can use them as if they were written in Perl.

RATIONALE

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" -- Donald Knuth

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. It should be clear that none such was available. If your code is too slow, you must make it faster. If no better algorithm is available, you must trim cycles."

97% of the time Perl is fast enough. In fact, in many problem domains, 99.7% of the time it's 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 making this transition.

"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

Inline::CPP just parses your C++ code and creates bindings to it. Like Inline::C, you will need a suitable compiler the first time you run the script. Choosing a C++ compiler can prove difficult, because Perl is written in C, not C++.

If you're one of the fortunate majority, you will accept the defaults as you install Inline::CPP. If you're one of the unfortunate (and shrinking) minority, read on.

Here's the rule: use any 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.

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

Inline::CPP is very similar to Inline::C, and in most cases can be used in place of Inline::C without changing a single line of Perl or C code. It 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 space, but will be available from other functions or classes within the C++ code.

For more information about the grammar used to parse C++ code, see the section called "Grammar".

The following example shows how C++ snippets map into the Perl namespace:

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, Perl's namespace 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 (and anyway, C++ wouldn't let you do that either, since extrafield wasn't defined).

C++ Compilation Phase

The first time you run a program that uses Inline::CPP, the C++ code will be compiled into an _Inline/ or .Inline/ folder within the working directory. The first run will consequently incur a startup penalty. However, the compiled code is cached, and assuming it's not modified, subsequent runs will skip the C++ compilation, and startup time will be fast.

While code is under development the default _Inline/ directory arrangement is probably fine. But eventually it's probably best to set up a specific .Inline folder. It's easy to do. The method is well documented in the Inline POD under the heading The Inline DIRECTORY.

Where to put C++ code

Inline C++ code can reside just about anywhere you want within your Perl code. Much of this is documented more fully in the Inline POD, but here are some basics:

use Inline CPP => 'DATA';

# Perl code here

__DATA__
__CPP__

// C++ code here.

Or....

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

Ok, so that takes care of where code can reside within a given file. But 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).

One big advantage to putting the C++ code in a module is that it can be shared by multiple scripts while only incurring that compilation startup penalty one time, ever.

For this reason, when placing the C++ code in a module, it's usually a good idea to specify where the _Inline directory should reside, and again that's covered in full detail in the Inline POD.

Basing (CPAN) Distributions on Inline::CPP

Taking the concept of code-reuse one step further, it is entirely possible to package a distribution with an Inline::CPP dependency. When the user installs the distribution (aka, the module), the C++ code will be compiled during module build time, and never again (unless the user upgrades the module). So the user will never see the startup lag associated with C++ code compilation.

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

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.

The Perl Namespace Issue

Let's say you use Inline::CPP like this:

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;

The issue is that the C++ class, "Foo" will be mapped to Perl below the Some::Foo namespace, as Some::Foo::Foo, and would need to be instantiated like this: my $foo = Some::Foo::Foo->new(). This probably isn't what the user intended. Use the NAMESPACE configuration option to set your base namespace:

use Inline CPP => NAMESPACE => 'Some';

Now, Foo falls under the Some heirarchy: Some::Foo, and can be instantiated as my $foo = Some::Foo->new(). This probably is what the user intended.

C++ Configuration Options

For information on how to specify Inline configuration options, see Inline. This section describes each of the configuration options available for C/C++. Most of the options correspond either to the MakeMaker or XS options of the same name. See ExtUtils::MakeMaker and perlxs.

ALTLIBS

Adds a new entry to the end of the list of alternative libraries to bind with. MakeMaker will search through this list and use the first entry where all the libraries are found.

use Inline CPP => Config => ALTLIBS => '-L/my/other/lib -lfoo';

See also the LIBS config option, which appends to the last entry in the list.

AUTO_INCLUDE

Specifies extra statements to be automatically included. They will be added on to the defaults. A newline char will automatically be added.

use Inline CPP => Config => AUTO_INCLUDE => '#include "something.h"';

BOOT

Specifies code to be run when your code is loaded. May not contain any blank lines. See perlxs for more information.

use Inline CPP => Config => BOOT => 'foo();';

CC

Specifies which compiler to use.

use Inline CPP => Config => CC => '/usr/bin/g++-4.6';

CCFLAGS

Specifies extra compiler flags. Corresponds to the MakeMaker option.

use Inline CPP => Config => CCFLAGS => '-std=gnu++0x';

FILTERS

Specifies one (or more, in an array ref) filter which is to be applied to the code just prior to parsing. The filters are executed one after another, each operating on the output of the previous one. You can pass in a code reference or the name of a prepackaged filter.

use Inline CPP => Config => FILTERS => [Strip_POD => \&myfilter];

The filter may do anything. The code is passed as the first argument, and it returns the filtered code.

INC

Specifies extra include directories. Corresponds to the MakeMaker parameter.

use Inline CPP => Config => INC => '-I/my/path';

LD

Specifies the linker to use.

LDDLFLAGS

Specifies which linker flags to use.

NOTE: These flags will completely override the existing flags, instead of just adding to them. So if you need to use those too, you must respecify them here.

LIBS

Specifies external libraries that should be linked into your code. Corresponds to the MakeMaker parameter.

use Inline CPP => Config => LIBS => '-L/your/path -lyourlib';

Unlike the LIBS configuration parameter used in Inline::C, successive calls to LIBS append to the previous calls. For example,

use Inline CPP => Config => LIBS => '-L/my/path', LIBS => '-lyourlib';

will work correctly. If you want to add a new element to the list of possible libraries to link with, use the Inline::CPP configuration ALTLIBS.

MAKE

Specifies the name of the 'make' utility to use.

MYEXTLIB

Specifies a user compiled object that should be linked in. Corresponds to the MakeMaker parameter.

use Inline CPP => Config => MYEXTLIB => '/your/path/something.o';

NAMESPACE

use Inline CPP => Config => NAMESPACE => 'Foo';
use Inline CPP => Config => NAMESPACE => 'main';
use Inline CPP => Config => NAMESPACE => q{};

Override default base namespace.

Under default behavior, a C++ class Foo created by invoking Inline::CPP from package Bar will result in the C++ Foo class being accessible from Perl as Bar::Foo. While this default behavior may be desirable in some cases, it might be undesirable in others. An example would be creating a Foo class while invoking Inline::CPP from package Foo. The resulting class will bind to Perl as Foo::Foo, which is probably not what was intended.

This default behavior can be overridden by specifying an alternate base NAMESPACE. Examples are probably the best way to explain this:

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.

As demonstrated here, the namespace in which "Baz" resides can now be made independent of the package from which Inline::CPP has been invoked. Consider instead the default behavior:

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.

It is probably, in this case, undesirable for the C++ class Foo to reside in the Perl Foo::Foo namespace. We can fix this by adding our own namespace configuration:

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.

Note: Due to an XS implementation detail, ref($b) will return main::Foo if the NAMESPACE configuration has been set to an empty string; XS doesn't allow for its internal PACKAGE specification to be empty. From a caller's standpoint this is probably not relevant; A class named main::Foo can be referred to as Foo, even from outside of package main.

PREFIX

Specifies a prefix that will automatically be stripped from C++ functions when they are bound to Perl. Less useful than in C, because C++ mangles its function names to facilitate function overloading.

use Inline CPP Config => PREFIX => 'ZLIB_';

This only affects C++ function names, not C++ class names or methods.

PRESERVE_ELLIPSIS

By default, Inline::CPP replaces ... in bound functions with three spaces, since the arguments are always passed on the Perl Stack, not on the C stack. This is usually desired, since it allows functions with no fixed arguments (most compilers require at least one fixed argument).

use Inline CPP Config => PRESERVE_ELLIPSIS => 1;
or
use Inline CPP Config => ENABLE => PRESERVE_ELLIPSIS;

For an example of why PRESERVE_ELLIPSIS is normally not needed, see the examples section, below.

STD_IOSTREAM

By default, Inline::CPP includes the standard iostream header at the top of your code. Inline::CPP will try to make the proper selection between iostream.h (for older compilers) and iostream (for newer "Standard compliant" compilers).

This option assures that it include iostream, which is the ANSI-compliant version of the header. For most compilers the use of this configuration option should no longer be necessary. It is still included to maintain backward compatibility with code that used to need it.

use Inline CPP => Config => ENABLE => STD_IOSTREAM;

STRUCTS

Specifies whether to bind C structs into Perl using Inline::Struct. NOTE: Support for this option is experimental. Inline::CPP already binds to structs defined in your code. Structs and classes are treated as the same construct, except that a struct's initial scope is public, not private. Inline::Struct provides autogenerated get/set methods, an overloaded constructor, and several other features not available in Inline::CPP.

You can invoke STRUCTS in several ways:

use Inline CPP Config => STRUCTS => 'Foo';
or
use Inline CPP Config => STRUCTS => ['Bar', 'Baz'];

Binds the named structs to Perl. Emits warnings if a struct was requested but could not be bound for some reason.

use Inline CPP Config => ENABLE => 'STRUCTS';
or
use Inline CPP Config => STRUCTS => 1;

Enables binding structs to Perl. All structs which can be bound, will. This parameter overrides all requests for particular structs.

use Inline CPP Config => DISABLE => 'STRUCTS';
or
use Inline CPP Config => STRUCTS => 0;

Disables binding structs to Perl. Overrides any other settings.

See Inline::Struct for more details about how Inline::Struct binds C structs to Perl.

TYPEMAPS

Specifies extra typemap files to use. These types will modify the behaviour of C++ parsing. Corresponds to the MakeMaker parameter.

use Inline CPP Config => TYPEMAPS => '/your/path/typemap';

C++-Perl Bindings

This section describes how the Perl variables get mapped to C++ variables and back again.

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.

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

Inline::CPP automatically includes <iostream>, or <iostream.h>, depending on the preference of the target compiler. This distinction illustrates a potential problem when trying to write portable code in C++. Legacy C++ (pre-ANSI-Standard) used headers named, for example, <iostream.h>. As legacy C++ didn't support namespaces, these standard tools were not segregated into a separate namespace.

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_INCLUDEs -- 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

Here are some examples.

Example 1 - Farmer Bob

This example illustrates how to use a simple class (Farmer) from Perl. One of the new features in Inline::CPP is binding to classes with inline method definitions:

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);
}

Example 2 - Plane and Simple

This example demonstrates some new features of Inline::CPP: support for inheritance and abstract classes. The defined methods of the abstract class Object are bound to Perl, but there is no constructor or destructor, meaning you cannot instantiate an Object.

The Airplane is a fully-bound class which can be created and manipulated from Perl.

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;
  }
};

Example 3 - The Ellipsis Abridged

One of the big advantages of Perl over C or C++ is the ability to pass an arbitrary number of arguments to a subroutine. You can do it in C, but it's messy and difficult to get it right. All of this mess is necessary because C doesn't give the programmer access to the stack. Perl, on the other hand, gives you access to everything.

Here's a useful function written in Perl that is relatively slow:

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

Here's the same function written in C:

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;
}

Here's a benchmark program that tests which is faster:

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;
}

Comparing the relative speed of the Perl versus the C++ solution, the C++ solution benchmarks about 10x faster.

Mind you, those both include the time taken to initialize the array with random numbers. And by varying the number of elements in the array and the number of repetitions of the function, we can change this number a lot.

What's the point? Of course C or C++ is faster than Perl. Well..., actually, that wasn't really the point; that was an aside. Look at the function declaration:

double avg(...)

Why didn't we need to use varargs macros to get at the arguments? Why didn't the compiler complain that there were no required arguments? Because Inline::C++ actually compiled this:

double avg(   )

When it bound to the function, it noticed the ellipsis and decided to get rid of it. Any function bound to Perl that has an ellipsis in it will have its arguments passed via the Perl stack, not the C stack. That means if you write a function like this:

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

then you'd better be reading things from the Perl stack. If you aren't, then specify the PRESERVE_ELLIPSIS option in your script. That will leave the ellipsis in the code for the compiler to whine about. :)

Example 4 - Stacks and Queues

Everyone who learns C++ writes a stack and queue class sooner or later. I might as well try it from Inline. But why reinvent the wheel? Perl has a perfectly good Array type, which can easily implement both a Queue and a Stack.

This example implements a Queue and a Stack class, and shows off just a few more new features of Inline::CPP: default values to arguments,

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;
};

Example 5 - Elipses Revisited (and Overloading or Templates)

This example of how to use elipses is adapted from a discussion on Perl Monks. The issue was that someone wanted to call overloaded functions. Perl doesn't understand C++'s overloading rules, and C++ has no idea how Perl intends to call the functions here. So we write a wrapper to take control ourselves:

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.
  }
}

Technically one of the versions of add() will bind to Perl, but it's fragile to use it, as the rules for which one binds are undefined. This example overcomes the issue of Perl/XS not understanding overloading by simply wrapping the calls to overloaded functions in a function that does understand. And we use elipses to deal with a variable number of arguments. This same approach can be applied to calling template-generated code as well.

Minimum Perl version requirements

As Inline currently requires Perl 5.6.0 or later. Since Inline::CPP depends on Inline, Perl 5.6.0 is also required for Inline::CPP. It's hard to imagine anyone still using a Perl older than 5.6.0 wanting to interface with C++, but if you're in that camp, you'll need to roll back Inline and Inline::CPP to older versions through the magic of backpan. Inline::CPP version 0.25 was still compatible with Perl 5.005_03. Review the Changes file from the Inline distribution to decide which Inline version is appropriate for your pre-5.6.0 Perl.

C++11 Standard

Occasionally I'm asked if Inline::CPP is ready for the C++11 standard. The short answer is mostly, to the extent that your compiler is C++11 standard compliant. There are two issues to consider. First, what is your compiler capable of (and how to you enable those capabilities), and second, what does Perl need to care about.

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 may also 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 (don't make sense to Inline::CPP anyway), and lambdas (which are still fine, because they take place inside of functions, so Inline::CPP doesn't see them anyway). For now, just don't use it in the header of functions that need to bind to Perl. This may get fixed in the future.

Now for another, 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

There are bound to be other bugs in code this uncivilized. If you find one, please file a bug report.

When reporting a bug, please do the following:

- If possible, create a brief stand-alone snippet of code that
  demonstrates the issue.
- Use rt.cpan.org's bug reporting facility:
  L<https://rt.cpan.org/Public/Dist/Display.html?Name=Inline-CPP>
- Patches are always welcome, as are tests that tickle a newfound bug.

...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 will always hold the latest stable CPAN release. (Stable releases have version numbers in the following format: 'x.xx'.)

The dev branch will hold a combination of minor commits and CPAN "Developer" releases (these will have a version number formatted as: 'x.xx_xxx').

Other 'topic' branches will come and go as needed.

Most discussion relating to this module (user or developer) occurs on the Inline mailing list, inline.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 noticed quickly. This is Perl, C++, and XS all sealed into one can of worms. But it can be fun, which is a description never applied to raw XS.

There are a number of smoke test FAILS that will only reasonably occur in a testing environment. Most of these are a result of the module being tested in parallel. It is unlikely that in a real-world environment compilation will ever take place in parallel.

AUTHOR

Neil Watkiss <NEILW@cpan.org> was the original author.

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

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

LICENSE AND COPYRIGHT

See http://www.perl.com/perl/misc/Artistic.html

To install Inline::CPP, copy and paste the appropriate command in to your terminal.

cpanm

cpanm Inline::CPP

CPAN shell

perl -MCPAN -e shell
install Inline::CPP

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)