Scripting C++ -- Boost.Python vs CORBA vs ???

[Ira D. Baxter]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:a5gk1u$hlu$1 at bob.news.rcn.net...
>
> "Craig Maloney" <cmaloney at physics.ucsb.edu> wrote in message
> news:6bf54244.0202260920.5920efc6 at posting.google.com...
> > Hi David.
> >
> > ... I would presume that any compiler (eg g++) would
> > create some internal representation, ...

> > Presumably the EDG front end is geared toward producing this information
> > in a format more suited to being used by the "wrapper generators" in
> > contrast with a compiler which produces this information only for itself
and with
> > the sole goal of compiling an object file?
>
> Not exactly. EDG makes a front-ends which they sell to vendors of full
> compiler solutions (Intel, KAI, Comeau, Compaq, ...). As such, their
> requirements for a well-defined and accessible intermediate representation
> (IR) are higher than other front-end writers.
>
> > What I'm getting at is that I'm confused as to why people wouldn't have
> > used information from the compiler *itself* to automate the process of
> > wrapper generation.
>
> They did. EDG's front end is part of many of the best C++ compilers.
>
> > Obviously the compiler writer people would have to
> > collaborate with the wrapper generator people...
> > but there must be  technical obstacles?
>
> What's in it for the compiler writer people?

Full employment? More importantly for EDG anyway, a broader market base.

There are other ways to tackle this problem.
One could build generic compiler front ends capable
of collecting all this data in an "accessible representation"
that isn't biased towards just a particular compiler,
and then populate a space of front-ends using
the generic infrastructure.  The value in
such a scheme is that you can use it for all
kinds of analysis and/or massive automated
change activitiies. of which wrappers is just
a particular application.

This is exactly what we've done with our DMS Software Reengineering Toolkit.
See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
That link also points to a wide variety of possible applications.

One of the issues to face is the problem of parsing nasty langauges
like C++, and deciding just exactly what you want from the "parse".
The EDG front end (I don't know a lot about it) is a "traditional"
compiler front end.   My unconfirmed guess is that for C++
it does preprocessing, and then builds intermediate representations
of the preprocessed text.

Now, if what you want to do is compiler-like, then throwing
away the comments, line numbering, number formats,
and preprocessor instructions is just fine.  And you
generally only have to focus on one "file" at time.

If, however, you want to modify the sources of the program,
*retaining* all that information, then you can't use
a conventional compiler technology front end.
You need to have something that can parse the sources,
*including* the preprocessor directives.
One of DMS's unique properties is its ability
to do that (with some constraints) for C and C++
code.

A second unique property is the ability to parse
entire suites of files in the same session, so
that you can build analysis tools that operate
across file boundaries (i.e., multiple compilation units)
and make modifications that move code/data
from one source file to another to accomplish
refactoring activities.

A third unique property of such generalized front ends
is the ability to *mix* notations from multiple programming
languages in patterns to enable translation from one langague/dialect
to another.

Of course, our hope is to be fully employed building/selling
reengineering tools rather than compilers.

--
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
http://www.semdesigns.com