I'm interested in using something other than the C preprocessor to preprocess my C and Objective-C source code. Are there good alternatives?
An example would be something that allowed one to escape out into a python or perl snippet in the middle of C code, and where the snippet spit out C that is then compiled as normal.
You can use PHP as a C preprocessor. The advantages are:
<? and ?> are not used in standard C (with non-standard C, the only thing that gets broken is old GCC extension operator that returns min/max)For serious use though, making PHP print the #line directives is needed for debugging preprocessed code.
<?php include_once "stdio.h"; ?>
int main()
{
<?php
for($i = 0; $i < 20; $i++)
echo 'printf("%d\n", '.$i.');';
?>
}
Cog isn't exactly a pre-processor, but it does go in-line in the code and generates stuff on the fly.
You might want to consider m4.
http://www.gnu.org/software/m4/
The idea that you run code, the result of which is then spliced in is called quasiquotation. The code you run is antiquoted.
I know how to solve this problem using Lua. I've used string.gsub with an antiquotation function I wrote myself. I've used shell syntax for the antiquotation. As in the shell the antiquoted code returns a string which is then spliced into the code.
Below prog is the C code with antiquoted text, and antiquote is the antiquotation function. I've used Lua's special string quoting double square brackets to full advantage. In practice you wouldn't do this; you'd put prog in a separate file.
names = { 'John', 'Paul', 'George', 'Ringo' }
local prog = [===[
#include <stdio.h>
main() {
$(local out = { }
for _, n in ipairs(names) do
table.insert(out, string.format([[ printf("The name is %%s\n", %q);]], n))
end
return table.concat(out, '\n ')
)
}
]===]
local function antiquote(s)
local body = s:match '^%$%((.*)%)$'
return assert(loadstring(body))()
end
prog = prog:gsub('%$%b()', antiquote)
io.stdout:write(prog)
In use, the program looks like this:
: nr@curlycoat 1181 ; lua /home/nr/tmp/emit-c.lua
#include <stdio.h>
main() {
printf("The name is %s\n", "John");
printf("The name is %s\n", "Paul");
printf("The name is %s\n", "George");
printf("The name is %s\n", "Ringo");
}
Sure, the standard C preprocessor is very limited.
I've done such a tool recently: https://github.com/d-ash/perlpp
For example this
<?
my @types = ('char', 'int', 'long');
foreach (@types) {
?>
<?= $_ ?> read_<?= uc($_) ?>(<?= $_ ?>* v);
<? } ?>
becomes this
char read_CHAR(char* v);
int read_INT(int* v);
long read_LONG(long* v);
Syntax is similar to PHP, but it uses Perl instead, and can capture texts into Perl stings.
Edit by cxw — With @d-ash's approval, I am also a maintainer of perlpp. If you have questions, feel free to drop me a line!
If you abstract your problem a bit, then you are in fact looking for a templating engine for your code. Just as most websites inserts dynamically generated content in static templates, you want to insert dynamically generated code into your program.
I currently use Jinja2 (Python) for most templating work - I've found it to be very configurable in every way.
If you're prepared to get your hands dirty with some C++, there's the Wave parser in Boost, which is built using the Spirit recursive descent parser. It's a complete C pre-processor that conforms to all the latest specs for C and C++ (and, by extension, Objective C, AFAICS).
It's highly modular so you can switch your own driver in that could do the extras you want.
I've thought about this same problem in the past. Make sure you are OK with the fact that anyone who wants to compile your code will need the new pre-processing tool as well. If you are the only one who will ever work on it, no problem, but if you want to make the code available to others, then you might want to consider whether or not adding a tool requirement is a good idea.
The short answer is "no." The preprocessor is so intimately tied to the semantics of C that you can't really remove it, and in fact in some compilers isn't even a separate phase like it used to be in the old days --- compiling Objective C on a Mac just parses the Objective C syntax. So while you could certainly use another macro-processor, like m4, to process your source text before passing it to C, you wouldn't be eliminating the C preprocessor, you'd be adding another step of preprocessing.
But there's a deeper question here: what do you want to gain by eliminating the CPP phase?
CPP does many important things for C code that you probably don't need re-implemented. What you seem to be looking for instead may be a templating process that emits C code.
Cheetah is just one of many that allows you to use python. There are others that use python and still more in other languages, but Cheetah is known for being output-agnostic where some templating engines are very heavily geared towards HTML/XML. Do your research.
You can use your favourite programming language to build a script/tool to generate source files (.c/.cpp or .h, or whatever). Simply #include them or compile them into your project. It may help to have comments near the #include to identify what/where the tool is and what is generated.
This may not be as handy (or clean) as using a "real" preprocessor, but it would work. Then again, it really depends on your case.
I see a 2001 paper introducing a python-like pre-processor http://ray.cg.tuwien.ac.at/rft/Papers/PYM/pym.html. It's not clear that anyone is using it..
I'd be interested to see what people come up with. I've tended to do small custom things with preprocessors written in Perl. It's easy to rig up a Makefile that calls the preprocessor. For example, here's a rule to call a program named 'meta' to generate 'file.c' from 'file.c.meta'.
% :: %.meta
meta $< > $@
I'm doing fun things with 'meta' like generating custom fit C data structures. It's definitely a direction I'd suggest exploring. My hope is to eventually come up with a meta library roughly parallel to C++ templates.
