473,239 Members | 1,596 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,239 software developers and data experts.

Embedded Perl or Python (XPost)

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
Jul 18 '05 #1
7 2445
In article <c9******************************@news.teranews.co m>,
Chris <re***@removethis.rebel.com.au> wrote:
Jul 18 '05 #2
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

Jul 18 '05 #3
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


Jul 18 '05 #4
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.


Jul 18 '05 #5
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
Jul 18 '05 #6
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
Jul 18 '05 #7
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

Jul 18 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Lionel | last post by:
Hi all, I would like having more informations on how we could exchange informations and/or objects between PERL and JAVA. We have a Java programs that open, maintain and close telnet...
5
by: John Benson | last post by:
Regarding the message appended below: I was in a similar situation, only I had 4 "small" (RAM-wise) legacy processors in a fault-tolerant Tandem K100 system. The system came with an old Borland C++...
42
by: Fred Ma | last post by:
Hello, This is not a troll posting, and I've refrained from asking because I've seen similar threads get all nitter-nattery. But I really want to make a decision on how best to invest my time....
31
by: surfunbear | last post by:
I've read some posts on Perl versus Python and studied a bit of my Python book. I'm a software engineer, familiar with C++ objected oriented development, but have been using Perl because it is...
3
by: Chris | last post by:
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...
0
by: Andrew Zhilenko | last post by:
Hello, Apparently Perl caches the value of the $$ variable (PID). So if it is a process with the embedded perl, and fork was performed not from within the Perl code, but by the C code 'outside'...
11
by: Mark Yudkin | last post by:
The documentation is unclear (at least to me) on the permissibility of accessing DB2 (8.1.5) concurrently on and from Windows 2000 / XP / 2003, with separate transactions scope, from separate...
13
by: squash | last post by:
I am a little annoyed at why such a simple program in Perl is causing so much difficulty for python, i.e: $a += 200000 * 140000; print $a;
8
by: Palindrom | last post by:
Hi everyone ! I'd like to apologize in advance for my bad english, it's not my mother tongue... My girlfriend (who is a newbie in Python, but knows Perl quite well) asked me this morning why...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.