Embedded Perl or Python (XPost)

[Chris]

Hi

I am posting this on both the perl and python groups

My intention is not to start a war or anything else, I would just like
some pragmatic advice.

My apologies to the python group I am not very conversant with Python at
this stage. that could change soon though.

OUTLINE

I am developing a software project where a major portion of it is to
enable script access to c++ classes

The idea is to extend the basic functionality of the program by allowing
third parties to write add ons that are called by my c++ classes as
virtual functions.

So if I call vfunction(); and an add on has been written that redefines
this function (and possibly calls the base c++ function) that it is
called correctly.

I have chosen perl and python as my preferred languages because of the
large developer base for add ons

The interpreter will only have a subset of the standard funtionality, for
example sockets will be removed.

QUESTION

Given the above which interpreter is most likely to fit my bill with the
smallest footprint ?

Thanks in advance
Chris

[Cameron Laird]

In article <c9******************************@news.teranews.co m>,
Chris <re***@removethis.rebel.com.au> wrote:

[Alex Martelli]

Chris wrote:
...

So if I call vfunction(); and an add on has been written that redefines
this function (and possibly calls the base c++ function) that it is
called correctly.

I have chosen perl and python as my preferred languages because of the
large developer base for add ons

The interpreter will only have a subset of the standard funtionality, for
example sockets will be removed.

QUESTION

Given the above which interpreter is most likely to fit my bill with the
smallest footprint ?

No idea about "footprint", partly because it so crucially depends on
what you will or won't remove. But trying it out for benchmark and
measurement is trivially easy for Python -- use Boost Python, which
you get from www.boost.org, and the "subclassing C++ in Python with the
possibility of overriding virtual functions" functionality is there.

Assuming it's just as easy for Perl (sorry, no idea), trying it for both
languages and measuring footprint should fit comfortably within an afternoon
with ample time left over for tea;-).
Alex

[Chris]

LOL

thanks for the heads up on Boost

I have just downloaded Swig and am beginning to explore that, So boost
also sounds like a good idea.

I think with my penchant for small things I may be getting carried away.

I guess suck it and see is my best option, I have explored the source
code for perl 5.8 and got considerably lost :(

I will have to try python and see if I come out any wiser

Regards
Chris
Alex Martelli <al***@aleax.it> wrote in
news:g_********************@news2.tin.it:

Chris wrote:
...

So if I call vfunction(); and an add on has been written that
redefines this function (and possibly calls the base c++ function)
that it is called correctly.

I have chosen perl and python as my preferred languages because of
the large developer base for add ons

The interpreter will only have a subset of the standard funtionality,
for example sockets will be removed.

QUESTION

Given the above which interpreter is most likely to fit my bill with
the smallest footprint ?

No idea about "footprint", partly because it so crucially depends on
what you will or won't remove. But trying it out for benchmark and
measurement is trivially easy for Python -- use Boost Python, which
you get from www.boost.org, and the "subclassing C++ in Python with
the possibility of overriding virtual functions" functionality is
there.

Assuming it's just as easy for Perl (sorry, no idea), trying it for
both languages and measuring footprint should fit comfortably within
an afternoon with ample time left over for tea;-).
Alex

[Chris]

Hi Cameron

Thanks for the interest.

when I say smallest footprint its because to me size does matter :)

I like my apps to be as small as possible for easy delivery.

So for example if PERL "requires" the whole package to be present then
it would be too bloated

I would like just a small as possible DLL or possibly statically link
the interpreter into my app with minimum external files

so my concerns are
can it be done
which will do it better
which will be faster. (some of the scripts will be called many times so
compounding speed is an issue) can I precompile to decrease load times ?
which will be the smallest in size?
Chris

cl****@lairds.com (Cameron Laird) wrote in
news:vl************@corp.supernews.com:

In article <c9******************************@news.teranews.co m>,
Chris <re***@removethis.rebel.com.au> wrote:
.
.
.

I am developing a software project where a major portion of it is to
enable script access to c++ classes

The idea is to extend the basic functionality of the program by
allowing third parties to write add ons that are called by my c++
classes as virtual functions.

.
.
.

Given the above which interpreter is most likely to fit my bill with
the smallest footprint ?

.
.
.
Let's be clear on what we're discussing. When you write,
"smallest footprint", do you seriously mean, "creates the
smallest differential in the size of the resulting exe-
cutable image"? Frankly, that would surprise me; your
project sounded interesting and useful up until those
last two words. I don't mean to be harsh; unless there's
something you're not telling us, though, the size of
executables-as-file-images is quite unlikely to be even
the tenth most important aspect of your target.

I'll anticipate a bit more, and observe that Python is
likely to be the better choice, because it remains easier
for a newcomer to extend-or-embed (it's not clear that
you've decided between these alternatives), at least until
Perl 6 meets all its goals.

[Alex Martelli]

Chris wrote:

LOL

thanks for the heads up on Boost
You're welcome.

I have just downloaded Swig and am beginning to explore that, So boost
also sounds like a good idea.
Personally, I prefer SWIG when what I have to interface to is basically
C code. In that case, SWIG does have the advantage of being able to
interface a C library to _several_ HLLs and VHLLs. But for C++ I never
really got the hang of it, while Boost and pyste are a snap to use (for
Python, which coversa basically all I need).

I think with my penchant for small things I may be getting carried away.
"Small binary size" is a perfectly respectable target when one's
target requires it (mobile phones, small palmtops, etc). Otherwise,
personally, I consider it way less important than productivity,
maintainability, correctness, and even speed. But if your priorities
are otherwise, you might consider LUA -- it probably won't do all you
want, but it may come near and it WILL be far smaller anyway.

Some scripting languages are designed for power, others focus on
being small. Perl and Python definitely consider power, ease of
use (by their very different criteria), and so on, far more crucial
than saving some bytes of disk. When that disk saving is crucial,
you may choose scripting languages designed to be small, even if
that sacrifices a lot of power -- after all, many scripting tasks
don't really require all that power.

I guess suck it and see is my best option, I have explored the source
code for perl 5.8 and got considerably lost :(
Ah, yes, I remember that feeling from back when I wrested with it
(Python's C source code I find very readable, and anyway you do not
need to look at it to use Boost or pyste).

I will have to try python and see if I come out any wiser

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

[Tassilo v. Parseval]

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
due to all the modules that come with Perl. Not sure whether the OP
needs all of them though.

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

But anyway, embedding Perl is known to be hard.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[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@lancelot src]$ size /usr/bin/ruby
text data bss dec hex filename
569672 4192 56768 630632 99f68 /usr/bin/ruby

[alex@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