Oops, D can compile and link C++, of course. On Thu, Oct 22, 2009 at 12:47 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
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