C Preprocessor Hell

The code in the article is actually less horrible than I expected from the title. However, it seems like a situation which could be more elegantly solved with X-Macros (http://drdobbs.com/cpp/184401387), provided that you consider X-Macros elegant.

X-Macros: you have a header file consisting of lines in the form of "FOO(name, type, defvalue);" and include it several times with different definitions for FOO.

Re: C Preprocessor Hell

#5

Post by jacquesm » Thu, Jan 12, 2012, 2:14 PM UTC

ge0rg wrote: post #4

The code in the article is actually less horrible than I expected from the title. However, it seems like a situation which could be more elegantly solved with X-Macros ( http://drdobbs.com/cpp/184401387 ), provided that you consider X-Macros elegant. X-Macros: you have a header file consisting of lines in the form of "FOO(name, type, defvalue);" and include it several times with different definitions for FOO.

I don't particularly like include files in the middle of structs, but it looks like X macros might work.

Thanks for the tip, I'll have a look at them to see if there is a way around that so that it would work from a 'top' included file as well.

The project I'm working on has a single 'master include' file and I'd hate to break that convention.

Re: C Preprocessor Hell

#6

Post by drblast » Thu, Jan 12, 2012, 3:35 PM UTC

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors.

You aren't required to only use the C source code transformation tools that a default install of GCC provides.

Re: C Preprocessor Hell

#7

Post by ctdonath » Thu, Jan 12, 2012, 3:55 PM UTC

"Lisp programmers should stop reading right now because they'll likely suffer severe injury of the jaw muscles as they laugh themselves silly at how hard it is to do some things in C."

Naive question: in Lisp, how would you set the byte at address 0xDEADBEEF to 0x42?

Re: C Preprocessor Hell

#8

Post by jerf » Thu, Jan 12, 2012, 4:10 PM UTC

drblast wrote: post #6

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors. You aren't required to only use the C source code transformation tools that a default install of GCC provides.

It introduces a new dependency on a new language that has no relationship to C. For local projects, sure, for projects you want to distribute it's risky.

If you're about to reply it's a risk you'd take... me too, in general. CPP sucks. But not wanting to introduce that risk is a valid choice in many cases.

Re: C Preprocessor Hell

#9

Post by anon_d » Thu, Jan 12, 2012, 4:15 PM UTC

drblast wrote: post #6

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors. You aren't required to only use the C source code transformation tools that a default install of GCC provides.

Yep. Why try to force a tool into a role it was never designed for? You use m4 or just write a preprocessor in any language. If you really want to do complicated lisp-style meta-programming stuff with C, just write another C program to pre-process your C program. It's more work, but it gives you complete control over the syntax.

Re: C Preprocessor Hell

#10

Post by plorkyeran » Thu, Jan 12, 2012, 4:17 PM UTC

drblast wrote: post #6

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors. You aren't required to only use the C source code transformation tools that a default install of GCC provides.

Using external programs to generate code nontrivially increases the required complexity of your build system, and unless you're targeting Linux only, it isn't really given that users will already have perl installed, much less a lisp interpreter.