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

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

Oops, D can compile and link C++, of course.

On Thu, Oct 22, 2009 at 12:47 AM, Christian Schladetsch <
christian.schladetsch_at_[hidden]> 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
>
>