Matthew Gillman wrote:
> Dear All
>
> I wrote a large C++ program which used embedded Perl. Later, this was changed to
>embedded Python. The reasons for this included:
>
> 1) Python allows you to pass a pointer to an object from C/C++ to the embedded
>Python interpreter, wheras Perl makes you push and pop off the stack (as far as I am
>aware - but I'm open to correction :-)
>
> 2) Embedded Perl generates vast numbers of Purify errors and memory leaks, although
>this is not the case with embedded Python.
>
> 3) Speed (I guess partially as a consequence of (1))
>
> Python has a very large C/Perl API, unlike Perl. Of course, the downside of this is
>that it is potentially more complicated. Also, in Python you have to keep careful
>track of reference counts to your embedded Python objects, so that's hard too.
>
> Basically, my comment is that a lot of commercial applications seem to be mixing and
>matching languages together (like C++ and Perl), so it would be really great if the
>issues such as Purify errors for embedded Perl were addressed (I realise that
>stand-alone Perl is well-Purify'd and tested). I should also stress that I have no
>particular axe to grind - I like both languages and have used both of them as
>appropriate.
>
> Sorry if you're not the person I should have sent this to! But I'd welcome any
>comments.
Yes, I agree with you that Perl kernel is too big to embed into other program.
Perlsonally, I don't think mod_perl is a success story, the main problem
is perl interpreter is too big and need so much memory, so build apache with perl
interpreter makes apache couldn't run fast as it should be.
I suggest Perl6 can give us a way to do "make miniperl", so it only export and install
mini
perl on system. Then we can embed the mini perl into other program.
>
>
> Thanks.
>
> Yours Sincerely
>
> Matthew Gillman
--
Sincerely,
Wei Ye
