Boost logo

Boost :

From: Lally Singh (lally.singh_at_[hidden])
Date: 2006-10-26 19:46:00


On 2006-10-21 21:19:22 -0400, Jeff Garland
<jeff_at_[hidden]> said:

>
>> the Wave preprocessor. This proved to be very helpful. We still
>> continue discussions with Lally until now, and it's a good thing!
>> The project continued even after SoC. I'm quite satisfied with the
>> results now.
>
> You guys might be interested to know that that the committee voted this
> week to create a TR for modules -- essentially removing it from C++0x.
> The major problem holding the feature back was the lack of an
> implementation. By creating the TR, the pursuit of the feature will
> continue, but an implementation is essential. Couple questions.
> What's the status of things? Any thought of moving over to gcc and
> implementing it there?

As a recap for anyone new to the whole project, I was the Boost SoC
student working on mfront, a preprocessor that took in Modular C++ and
converted it back to C++ for final compilation. It used Wave as a
preprocessor, and Spirit as a parsing library, with a slightly modified
version of the Hannibal C++ grammar. The grammar is far from complete,
but parses a good amount of C++.

Modular C++ allowed constructs such as this:
> // File_1.cpp:
> export Lib { // Module definition header.
> // Must precede all declarations.
> import std;
> public:
> struct S {
> S() { std::cout << “S()\n”; }
> };
> } // End of module definition (last token).
>
> // File_2.cpp:
> import Lib;
> int main() {
> Lib::S s;
> }

It doesn't have a full C++ grammar, nor does it maintain a symbol
table. Also, it outputs C++, which prevents it from doing any language
transformations that require changes in C++ semantics (without
re-implementing parts of C+++).

Currently, it parses and transforms the base Modular C++ language,
along with a module partitions and embedded modules. It can't do the
changes in name lookup required, nor does it do some of the 'extras'
that weren't part of the core language (e.g. a program module, module
startup/shutdown methods, etc.) --- those were left as post v1.0
features.

It works by preprocessing its input, transforming the text, and then
emitting 3 things:
- a source file, to pass into the C++ compiler
- a header file
- a .map file.

The latter two are used for conversion. The .map file declares what
modules are defined in which files. The header files are #included by
other source files importing the current module.

It currently works on Mac OS X, but it's just plain C++ with Boost on
it. It compiles on Win32 out of the box. It just needs configuration
files written for setting up #include paths, and #defines relevant for
the platform. I'm working on Win32 right now, Linux is next. The
prioritization order for that work's based the order of which systems
are available to me at which time.

 As for implementation under GCC instead of as a preprocessor, I
think that effort spent in extending the grammar (hannibal) to cover
more C++ would have more immediate benefits:
- A publically available C++ grammar!
- mfront could then become a general testing tool for experimental C++
features.

Of course, that'd require we have mfront build a symbol table too, but
that'd be just as useful as the grammar itself.

The transform engine in mfront is pretty generic, and forms a good
basis for experimenting with new C++ features, as long as they can be
transformed back into normal C++. IMHO they're a lot easier (full C++,
easy access to the input text, only have to output normal C++ text
instead of gcc trees) than implementing the equivalent in gcc.

Of course, if changing the semantics of C++ is desired, then another
solution will be necessary -- mfront would have to translate to C, with
the semantics of C++ re-implemented. At that point, modifying an
existing compiler's preferable.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk