On-the-fly compilation and execution of C++ program

[Raxit]

Hi,
we are designing some stuff , that will generate c++ program(s)
What we want is we wanted to execute that generated code....

i.e.
1. Xml based language
2. C++ code generated from 1.[Its mapping between 1 & 2]
3. compilation
4. execution.

What we have got stucked at compilation, we want that our user should
not take care about compilation or c++ code generation etc...They just
write some xml "code" and it should execute !

[we are developing something like Event processor, reactor system etc]
-Raxit

[Matthias Buelow]

Ra***@MyKavita. com wrote:

What we have got stucked at compilation, we want that our user should
not take care about compilation or c++ code generation etc...They just
write some xml "code" and it should execute !

That thing has existed for over 50 years and is called "Lisp".

[klmillr1]

On Jun 2, 4:04 am, James Kanze <james.ka...@gm ail.comwrote:

On Jun 2, 7:47 am, Walter Bright <wal...@digital mars-nospamm.com>
wrote:

http://www.digitalmars.com/dscript/index.html

That's actually a very good suggestion. Javascript, perl,
python, and probably a couple of other languages have
interpreters which you can directly link into a C++ program.

Add Lua to that list. The Lua/C interface is modeled as a stack of
value-typed variables, and it's incredibly easy to integrate into C or
C++ projects.

[James Kanze]

On Jun 2, 4:28 pm, Matthias Buelow <m...@incubus.d ewrote:

Ra...@MyKavita. com wrote:

What we have got stucked at compilation, we want that our
user should not take care about compilation or c++ code
generation etc...They just write some xml "code" and it
should execute !

That thing has existed for over 50 years and is called "Lisp".

Lisp can execute XML? (I'll bet it couldn't 50 years ago.)

Just about any interpreted language can, at least in principal,
take a string and execute it---I've even seen some Basic's which
can do it. Compiled languages, like C++, typically don't carry
the weight of a compiler around with them. About the only thing
special about Lisp (and its dialects, like Scheme) here is that
is remarkably easy to compile, so the extra weight is
considerably less (although the executable for scheme, on my
system, is still more than 3.5 MB). Historically, of course,
Lisp was the first interpreted language.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Walter Bright]

James Kanze wrote:

Lisp can execute XML? (I'll bet it couldn't 50 years ago.)

No, but it's been pointed out that the only fundamental difference
between Lisp and XML is that Lisp can be executed.

[Matthias Buelow]

James Kanze wrote:

Lisp can execute XML? (I'll bet it couldn't 50 years ago.)

:)

What I wanted to say is that the rôle that "executable XML" is supposed
to occupy is traditionally (and imho, much better) filled in by a Lisp
dialect of some sorts. They have a head-start of almost 50 years on XML
and Lisp S-expressions are (imho) more readable than XML.

The idea, of course, being that instead of somehow trying some awkward
construct to turn XML into C++ and feed that to an external compiler and
then load the generated object file (or somesuch), it might be more
productive to use S-expressions instead of XML, and embed a Lisp system
in the (C++) application.

[Matthias Buelow]

Walter Bright wrote:

No, but it's been pointed out that the only fundamental difference
between Lisp and XML is that Lisp can be executed.

Or as John McCarthy says: "XML is isomorphic to the subset of Lisp data
where the first item in a list is required to be atomic."

(http://www-formal.stanford.edu/jmc/cbcl2/node4.html)

[James Kanze]

On Jun 3, 1:38 pm, Matthias Buelow <m...@incubus.d ewrote:

James Kanze wrote:

Lisp can execute XML? (I'll bet it couldn't 50 years ago.)

:)

What I wanted to say is that the rôle that "executable XML" is
supposed to occupy is traditionally (and imho, much better)
filled in by a Lisp dialect of some sorts. They have a
head-start of almost 50 years on XML and Lisp S-expressions
are (imho) more readable than XML.

Yes, but Lisp isn't "in", and XML is. So obviously, a new
project can't use Lisp, and must use XML.

The idea, of course, being that instead of somehow trying some
awkward construct to turn XML into C++ and feed that to an
external compiler and then load the generated object file (or
somesuch), it might be more productive to use S-expressions
instead of XML, and embed a Lisp system in the (C++)
application.

And XML probably maps easier into Lisp than into C++. (There is
a basic simimlarity of structure.) So you can still keep the
XML to show to the customer, and be in, and use a Lisp
interpreter to do the real work:-). (Most of the time I've had
to generate code automatically, it's been mainly tables, and
nested structures do map fairly easily into C++, although if the
structures are dynamic, you end up needing a lot of pointers.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]