Re: [boost] The C++ Post-Processor

Subject: Re: [boost] The C++ Post-Processor
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-10-21 09:47:42

First, thanks for all your thoughts and effort in the responses. Your kind
and valued attention has helped me to better formalise my original thoughts,
and I am grateful.

[snip]

#function f(x,y) x + y + 1
>

> The intention is that such expressions will be evaluated by first extending
> any #function or #define macros, and then evaluating the resulting
> expression. This would simplify much of the current preprocessor.
>

This is along the lines of the intention of my original post; to come up
with constructive ideas on how to extend the PP to service our needs.

To address a previous query, yes I am aware of and use Boost.PP (mostly to
deal with tedious issues arising from arity), however it is awkward and hard
for others in my team to use, and breaks the debugger.

So I'll add that to my wishlist: any extensions to the PP should also assist
with debugging which is currently pathological in some cases.

Others have wondered aloud about my intent or purpose with this thread. I
wished to start a wider discussion about how the PP is currently used and
why, and how it can be enhanced. Specifically, how we can use Boost.Wave (or
ANTLR!) to enhance the PP and avoid some of the extremely clever yet
excruciating tricks and hacks it uses.

Seriously - if the author of Boost.PP could just remake the PP I'd be happy.
He knows it better than most of us.

So, ideas like #function are very welcome. I'll add one:

#{
#local ident = <expr>
#}

I don't mean this as a literal and serious proposition; but really, we need
scopes in the PP. And/or namespaces.

The other half of my original motivation for this thread is to make C++ more
elastic in general; not only in terms of constructing the tokens required,
but also in interpreting those tokens. This to me is a mirror of the first
issue. Even as I wonder about how to improve the PP (which generates code),
I also wonder about how to fold that with a P (which interprets it), and
wonder about the commonality between those processes.

I am pleased that a previous reply questioned my use of "Post-Processor" in
the subject, given that the body was about the PP. I carefully intended to
introduce that ambiguity. My intent was to get some energy behind the idea
of using C++ source code as an output, and treating C++ as a target platform
That is, you do some thinking and work in C+++, which outputs C++ (including
the PP), which then goes through the common C++ build.

P3 is a good name for this; P2 is the current PP++ and P1 is the current
runtime++. And P3 is better than C+++.

I wonder what the result would be if the great minds that input to boost
could instead turn their fantastic faculties to resolving the inherit
problems in C++, rather than constantly working around them.

I wonder what P2 would look like if the author of Boost.PP was given free
license (and support). I wonder what a dynamic C++ runtime, P1, would look
like if Joel was given free license to create one (and support). And I
wonder what P3 would look like if we could make it.

I wonder what could be created if we just shifted a little to the left. A
key motivation for the existence of boost is the improvement of C++ - not
just as a space for clever and esoteric ways to work around known faults.

C++ won't be changed quickly and for good reason. But I am not alone in my
impatience. Rather than simply moving my team wholly to the .NET framework,
I want to give C++ another chance.

It is not unnoticed to me that obvious efforts like #local and #function
above to introduce scope to the PP look a lot like COBOL. And this is almost
2010. My heart sinks.

D is an effort to address some of these issues, but it doesn't go far enough
in some respects and too far in others. I think D is worthy, but I don't
think D is the next C++. The next C++ has to be able to compile and link
with C++.

So, my question is, is C++ the next C++? Can C++ be used to create C++? How?
After some thought, I realised that the low-hanging fruit here is in the PP,
which is ancient and needs a LOT more love.

Some key ideas have come out of this discussion to me already; such as how
to deal with compile-time constants in different compilation units (in
response to my rant about game build systems) - but that is also an
underlying problem with current C++. Rather than proclaiming "Oh, It's too
hard, what about project settings" - we need to be thinking about "how do we
make the project settings part of the substance of the thing that is used to
build the project".

Rather than fly off into complete hyperspace, I'll stop now. But please,
hear the cry of many C++ developers: we envy some features and are getting
tired of being defensive. .NET is awesome; it's cross-platform, performant,
and reflected. Better we address that now, if we can, or just confine
ourselves to the COBOL of the future.

Regards,
Christian