Python vs. Perl
adjih at crepuscule.com
Wed May 23 05:11:43 EDT 2001
Rob Nikander <nikander at mindspring.com> wrote:
> In article <slrn9gluo4.8icv.dek at socrates.cgl.ucsf.edu>, "David Konerding"
> <dek at cgl.ucsf.edu> wrote:
>>> I haven't used much Perl, but there is a huge difference from C/C++
>>> because you can do dynamic stuff like:
>>> str = getCommandFromSomewhere()
>>> exec str
>> Eh, you could always add some code to your app which inserts the code
>> into a text file, compiles it, and dlopen's it, but I've never actually
>> seen somebody do that :-)
> I thought of a hack like that too... but I am not too familiar with dlopen...
The Python way is sometimes used a level higher by simply storing
all the data as Python code (or pickled code):
and recovered with something like:
which are a bit harder to do in C/C++.
> Question: The code in the exec can make reference to variables that are "local"
> to the place where "exec str" is. It inherits the local symbols. That is not
> going to happen with the dlopen(), right? The "symbols" that were part
> of a C program aren't around when it is compiled and running.
The global ones are. Thats if you have a global "double x;" in your
main C program and a shared library that declares a "extern double x;" and
uses it, at dlopen time, the external "x" symbol of the library would be
bound to the address of the "x" of the main program.
> It would be pretty cool if there was a way to do a similar thing in C (without
> reinventing Python/Lisp/etc). Maybe adding debug info to the executable
> keeps enough symbol information around to pull this off?
Well if you want to modify a variable in C/C++, you just
pass a pointer to it. Globals are available also with dlsym(...),
but I doubt you can manage to modify the locals of the calling
function...it would be peek and poke on the stack and fiddle with
the stack pointer ; it would be very ugly.
More information about the Python-list