11–20 of 30 posts
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.
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.
No it doesn't. It only requires a single rule in your Makefile. Something like:
%.c: %.cpre preprocess.pl; ./preprocess.pl $@Earlier quoted context omitted.
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.
nontrivially increases the required complexity of your build system. No it doesn't. It only requires a single rule in your Makefile. Something like: %.c: %.cpre preprocess.pl; ./preprocess.pl $@
The usual workaround for such situations is to add the preprocessed files into source control as well, so they are available when a user is building the code. However, this ends up even more ugly.
"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?
Earlier quoted context omitted.
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.
nontrivially increases the required complexity of your build system. No it doesn't. It only requires a single rule in your Makefile. Something like: %.c: %.cpre preprocess.pl; ./preprocess.pl $@
"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?
There are some who would suggest that allowing you to commit segment violations is not generally a desirable language feature.
"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?
There are some who would suggest that allowing you to commit segment violations is not generally a desirable language feature.
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.
Doing weird things to a C file (while occasionally useful) is just increasing the technical debt of your teammates later.
(though, we do have a closure-ish macro in our codebase that's pretty nifty, so do as I say not as I do etc.)
Earlier quoted context omitted.
There are some who would suggest that allowing you to commit segment violations is not generally a desirable language feature.
The ability to commit segment violations is a consequence of the broader abilities you get with pointers as a language feature. In many cases, neither of those things are desirable, but there are cases (e.g., systems programming) where they are very desirable.
Earlier quoted context omitted.
nontrivially increases the required complexity of your build system. No it doesn't. It only requires a single rule in your Makefile. Something like: %.c: %.cpre preprocess.pl; ./preprocess.pl $@
As was already stated: it isn't really given that users will already have perl installed . The usual workaround for such situations is to add the preprocessed files into source control as well, so they are available when a user is building the code. However, this ends up even more ugly.