
The Brick Wall of C++ Source Code Transformation - jsnell
http://scottmeyers.blogspot.com/2015/11/the-brick-wall-of-c-source-code.html
======
mynegation
I have been one of the primary authors of a commercial C++ static analysis
tool.

In a nutshell: C++ is horribly complicated language, and preprocessor is just
the first brick wall on the way. Even if you walk around it or manage to blow
a hole through it, there are other things. The fact that C++ even as a
preprocessed language is very complicated. Its grammar is context-sensitive.
You have to scan C++ definitions at least twice to parse them properly. And
then you bump into a mother of all brick walls: templates. Which are turing-
complete. Meaning that you can specify arbitrary computation in them, that
will be performed by the compiler.

------
aconz2
I've been thinking a lot about source code transformations as a possible key
for maintenance in the "future" of programming. Its interesting to see that
the preprocessor, which is a source code transformation itself, makes other
source code transformations much more difficult, if not intractable. I'm
wondering if this inherent to any macro system since they are not bijective.

Two possible directions I see away from macros which would play nicely with
source code transformations are un-macros and layers of languages.

Un-macros would take source and display it in the condensed form only for
human reading -- this takes away from human writing power of course, which may
have to get pushed into the editor. This could also allow for automated
pattern discovery.

Layers of languages would look similar to Racket's #lang concept and current
macro systems, but without the ability to escape back into the parent
language. This creates a new language on top of -- not mixed into -- the
parent language.

~~~
lmm
I wonder if the right option is to push the macro-like functionality down into
the language itself. Something like [http://okmij.org/ftp/Computation/free-
monad.html](http://okmij.org/ftp/Computation/free-monad.html) starts to offer
very macro-like functionality, but deferred to runtime, so you can still look
at the original value and even imbue its effects with a different set of
semantics.

~~~
amyjess
Or something similar to Nim's metaprogramming features. Nim's templates and
macros are wonderful.

~~~
aconz2
Are Nim's metaprogramming features fundamentally different than C++?

------
joakleaf
In short, the problem is that you can't do:

readable code -> [preprocessor transform] -> transformed code -> [apply
transformation tool] -> [reverse preprocessor transform] -> readable code

Because both the preprocessor (and potentially arbitrary transformation tool?)
are not bijective.

Couldn't you add detection for when the reverse transformation isn't
bijective, and then report an error in those cases.

Just because there are examples of abuse of header files and macros in C++, it
doesn't mean all of it is like that -- especially modern C++. So these tools
could still work for a lot of cases.

Please, don't give up!

~~~
pjmlp
I heard on CppCast with Dmitri Nesteruk, that CLion is macro aware when doing
refactorings, but it was a very complicated process to make it work properly.

Since I spend most of my days in JVM/.NET land, I don't have experience how it
really works.

They keep in memory the whole macro -> expanded C++ code transformation.

------
pldrnt
So, my after-work project these days is a language that transpiles to C++ and
can do all that current C++ can do.

The grammar is completely regular, and the syntax maps 1:1 with the ast in
memory, I can generate one from the other idempotently.

The main reason I am doing this is that I wanted a language that is easy to
build tooling for (including of course code transformations) while being
compatible with existing C++ libraries out there.

This kind of articles give me hope there might actually be demand for my crazy
thing once it grows up.

~~~
madmoose
Any relation to
[http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...](http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html)
?

~~~
pldrnt
I read that paper a long time ago and it was certainly an inspiration :)

Originally, the language started out quite different but I can now see why
SPECS looks the way it does, I do not agree with everything they did and my
effort these days is towards making it simpler and smaller but there's some
convergent evolution indeed.

------
raverbashing
And that's why the modern alternatives have done away or greatly reduced what
the preprocessor can do.

That and Include Files

I guess it was part of the evolution and experimentation, but it is one of the
things that make C++ complicated

------
petke
Thankfully we will get modules in C++ soon. Hopefully the (Microsoft) version
that deprecates the preprocessor.

------
zaro
Don't mean to be rude or troll but the first thing that came to my mind when I
saw the title was :

Stop trying to make C++ happen, it's not going to happen.

~~~
ska

       Stop trying to make C++ happen, it's not going to happen.
    
    

That isn't rude or trollish, but it _is_ inept.

