|preprocessing C++ with new features email@example.com (Lorenzo Bettini) (2003-03-30)|
|Re: preprocessing C++ with new features firstname.lastname@example.org (2003-03-30)|
|Re: preprocessing C++ with new features email@example.com (Ira Baxter) (2003-03-30)|
|Re: preprocessing C++ with new features Nicola.Musatti@ObjectWay.it (2003-03-31)|
|Re: preprocessing C++ with new features firstname.lastname@example.org (2003-04-13)|
|Re: preprocessing C++ with new features email@example.com (Lorenzo Bettini) (2003-04-15)|
|Re: preprocessing C++ with new features Thomas.Aigner@bfd-r.bayern.de (Thomas Aigner) (2003-05-23)|
|From:||firstname.lastname@example.org (Hans Aberg)|
|Date:||30 Mar 2003 21:16:19 -0500|
|Posted-Date:||30 Mar 2003 21:16:19 EST|
Lorenzo Bettini <email@example.com> wrote:
>I would like to add some new features to C++ and so I'd need mechanisms
>for preprocessing C++ code in order to handle only the new features and
>thus to generate new (translated) C++ code.
The approach I used was to write my own language using a Flex/Bison
lexer/parser generator combination. I included some constructs for
including C++ code verbatim, which makes it possible to add new,
non-C++ features, as one goes along.
In this setup, it turns out not be very practical to let the program
to write C++ code directly from the parser actions, in view of that
the same piece of data in my language may call for information to be
written in several different locations in the C++ output. For example,
a construct may call for certain header to be included, sometimes
written in a header file and sometimes in a source file, information
before and inside a C++ class in the header file, as well the
definition in a source file.
So in order to handle this problem conveniently, I wrote a macro program
which the actions of Bison generated parser writes into. Then this macro
program writes out the final C++ information into suitable source and
header files. This way I do not have to keep track of locations and the
order of the final C++ output when writing the parser actions. The
approach might be suitable for a multiple output language approach as
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <firstname.lastname@example.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
Return to the
Search the comp.compilers archives again.