Templating preprocessor for C

cyent · 02-25-2013, 08:20 PM

One of the (many) things I truly hate about the C preprocessor and C++ templates instantiation is although they create input to the compiler....

Their output (the compilers input) is neither visible (by default or to gdb) or readable (if you intercept it).

In principle, there is no reason why a C / C++ file cannot be run through some sort of templating pre-processor and output perfectly human readable C/C++ as an intermediate file.

It would be trivial to knock up ruby pre-processor that does something like this... but a couple of things are awkward to manage... (limiting scope, variable instantiation, token-pasting, stringification, handling expansion tokens in comments and strings...)

Not impossible, I could do something.... but hey, I'd hate to reinvent the wheel.

Does anyone know of an open source templating / macro engine that inputs beautiful human readable template definitions and outputs beautiful human readable C.

I don't think m4 qualifies as beautiful human readable input.

If all else fails cpp -P -C | indent might work.

All suggestions welcome - thanks.

Sergei Steshenko · 02-26-2013, 02:25 AM

Quote:

Originally Posted by cyent

One of the (many) things I truly hate about the C preprocessor and C++ templates instantiation is although they create input to the compiler....

Their output (the compilers input) is neither visible (by default or to gdb) or readable (if you intercept it).

In principle, there is no reason why a C / C++ file cannot be run through some sort of templating pre-processor and output perfectly human readable C/C++ as an intermediate file.

It would be trivial to knock up ruby pre-processor that does something like this... but a couple of things are awkward to manage... (limiting scope, variable instantiation, token-pasting, stringification, handling expansion tokens in comments and strings...)

Not impossible, I could do something.... but hey, I'd hate to reinvent the wheel.

Does anyone know of an open source templating / macro engine that inputs beautiful human readable template definitions and outputs beautiful human readable C.

I don't think m4 qualifies as beautiful human readable input.

If all else fails cpp -P -C | indent might work.

All suggestions welcome - thanks.

Have a look at https://www.linuxquestions.org/quest...e-like-674387/ and ask me further questions if interested

. If the source isn't there, I'll send it to you or place somewhere on the web.

ntubski · 02-26-2013, 09:05 AM

FYI, the latest gcc (4.8) can show macro context of errors:

Quote:

http://gcc.gnu.org/gcc-4.8/changes.html

The option -ftrack-macro-expansion=2 is now enabled by default. This allows the compiler to display the macro expansion stack in diagnostics. Combined with the caret information, an example diagnostic showing these two features is:

Code:

    t.c:1:94: error: invalid operands to binary < (have ‘struct mystruct’ and ‘float’)
     #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                                                  ^
    t.c:7:7: note: in expansion of macro 'MYMAX'
       X = MYMAX(P, F);
           ^

And with debug level 3 (-g3) includes macro information:

Quote:

http://gcc.gnu.org/onlinedocs/gcc/De...g-Options.html

Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.

No help for C++ templates though.

johnsfine · 02-26-2013, 10:23 AM

Quote:

Originally Posted by cyent

One of the (many) things I truly hate about the C preprocessor and C++ templates instantiation is although they create input to the compiler....

Their output (the compilers input) is neither visible (by default or to gdb) or readable (if you intercept it).

The "preprocessor" output is very well defined and about as readable as such a thing could be and is in the source language C or C++.

I don't think template instantiation output is available in the source language or in any readable form.

Quote:

In principle, there is no reason why a C / C++ file cannot be run through some sort of templating pre-processor and output perfectly human readable C/C++ as an intermediate file.

I think such a "templating pre-processor" would need to include the entire front end of a C++ compiler, plus extra functions to get back to source code format.

The C preprocessor was intentionally designed with nasty (from a C programmer's viewpoint) limitations to make it easy to separate a C preprocessor from a C compiler.

Templating has no similar restrictions. The whole front end of a C++ compiler is needed to understand C++ code well enough to do template expansion.

Quote:

It would be trivial to knock up ruby pre-processor that does something like this

I doubt it.

Quote:

but a couple of things are awkward to manage.

Understatement.

Quote:

token-pasting, stringification, handling expansion tokens in comments and strings.

Those aren't trivial on their own. But in comparison to the hard problems of template expansion, the fact that you list those at all means you are missing the real work.

cyent · 02-26-2013, 09:56 PM

Quote:

Originally Posted by johnsfine

I think such a "templating pre-processor" would need to include the entire front end of a C++ compiler, plus extra functions to get back to source code format.
>snip<
Templating has no similar restrictions. The whole front end of a C++ compiler is needed to understand C++ code well enough to do template expansion.

Hmm. Interesting.

Apart from the complexity of understanding the scope of a template parameters.... I thought it was a pretty much mechanical replace all template parameters with whatever it is instantiated with.

Thereafter much of the dark magic is about function overloading.

Which parts of template instantiation step (prior to handling overloading) do you feel requires a full compiler?

Quote:

Those aren't trivial on their own. But in comparison to the hard problems of template expansion, the fact that you list those at all means you are missing the real work.

Well those "easier" problems turned out to be pretty much non-problems. I now have 120 lines of ruby that does 90% of what I want.

The hard problem now seems to be generating separate header and .c files in a DRY fashion. Which sort of implies I need to create a facility to #include .template files and track the dependencies. Hmm.

cyent · 02-26-2013, 10:00 PM

Quote:

Originally Posted by Sergei Steshenko

Have a look at https://www.linuxquestions.org/quest...e-like-674387/ and ask me further questions if interested

. If the source isn't there, I'll send it to you or place somewhere on the web.

Ok, interesting design... Pretty much like the erb (Embedded Ruby) / PHP thing - except with perl.

Hmm. Sort of aiming for something simpler.... closer to cpp -E -P | indent.

but I will keep that in mind.