Embedded Perl or Python (XPost)

[Alex Martelli]

Tassilo v. Parseval wrote:

> Also sprach Alex Martelli:
> 
> [ embedding an interpreter ]
> 
>> Another option you may want to consider is Ruby.  I don't know
>> how easy it is to interface it specifically to C++, and in
>> particular to get the cross-language subclassing and overriding
>> effect you want (which Boost provides so smoothly) -- but it's
>> basically the same power as Perl or Python, a distinctive style
>> of its own that along some axes lies in-between the two P's,
>> and a small but enthusiastic community.  Size-wise, though, I
>> don't think it will significantly help you.
> 
> The C interface of Ruby is very simple and clear (likewise the C code in
> which Ruby was written). It almost made me cry when I saw it and
> compared it to that of Perl. :-) It's probably also smaller than both
> Python and Perl. I don't know about Python, but Perl's unwrapped source
> is currently well beyond 50meg. In compiled form it's still pretty large

For Python, I count 1.8 MB of .h files, 7.6 MB of .C files, and
1.8 MB of .py files.  Of course, that includes all sort of things
such as the RISCOS and Mac/OS implementations, the Tkinter GUI
library, the IDLE integrated development environment, and a
bazillion other tools, unit and integration tests, and "weird" library
modules (Python lacks Perl's CPAN, so far, but does have a huge included
library).

In terms of compiled size, I see:

[alex at lancelot src]$ size /usr/bin/ruby
   text    data     bss     dec     hex filename
 569672    4192   56768  630632   99f68 /usr/bin/ruby

[alex at lancelot src]$ size /usr/bin/python*
   text    data     bss     dec     hex filename
 514283   90792    9240  614315   95fab /usr/bin/python2.1

(these are the latest statically linked ones I have around)
so the sizes would appear to be very directly comparable (sorry,
no statically linked perl around for comparison!).

> due to all the modules that come with Perl. Not sure whether the OP
> needs all of them though.

He did say he plans to cut things out selectively (e.g. sockets).


> The bridge to C++ should not be so hard considering that a C++ compilers
> wont mind to include C code as well (or can at the very least easily be
> convinced to do so).

Ah, but what the OP wants is specifically for (Python/Perl/Ruby) classes
to be able to inherit from C++ classes, override some methods, and be
callable from C++ with the overridden methods smoothing and transparently
executed.  That's far from being as simple as it sounds -- it just can't
be done at a purely C level, and Boost Python does manage to pull it off
with much C++ template metaprogramming (David Abrahams, Boost Python's
author, is one of the true magicians in this specific area).


Alex