4 ms·

Some people hate the preprocessor. I love it. I miss it in every language that doesn't have one. I'd much rather be able to write statement statement

Some people hate the preprocessor. I love it. I miss it in every language that doesn't have one. I'd much rather be able to write statement statement statement #if DEBUG_FEATURE_X statement statement statement #endif statement statement statement than statement statement statement // remember to comment this code out statement statement statement // --- end of debugging code statement statement statement nor do I want a runtime check Of course ultimately I just wish C/C++ and every other language let you use the entire language at compile time like lisp (and a few others). As for more advanced macro foo macro lists are my favorite http://games.greggman.com/game/keeping_lists_in_sync_in_c__/ http://games.greggman.com/game/keeping_lists_in_sync_in_c__/ I know some people don't like them. Typically those people would solve the issue by using some other language, python, to generate C/C++. I'd prefer not to have yet another dependency.

marvy 11y ago
There's no need to worry about a runtime check. Let DEBUG be a compile time constant, and the optimizer will remove the check. C++ seems to be (very) slowly moving in the direction of using the whole language at compile time: see how constexpr has been getting better. I doubt it will ever get anywhere near what lisp lets you do though, and in those cases the preprocessor sure does help at least partially fill the gap. This is my favorite explanation of the technique you linked to: http://journal.stuffwithstuff.com/2012/01/24/higher-order-macros-in-c/ http://journal.stuffwithstuff.com/2012/01/24/higher-order-ma...
- nkurz 11y ago
  Let DEBUG be a compile time constant, and the optimizer will remove the check. What do you feel is gained with "const int DEBUG" over "#define DEBUG"? While most compilers will do what you say most of the time, I haven't encountered a significant downside to the macro approach. I also like that I can have a makefile where "make debug" adds "-DDEBUG" to the compiler command line and appends "_debug" to the executable name. With the const approach, is there an easy way to automatically generate both debug and production executables?
  - majewsky 11y ago
    I guess the argument is orthogonality. It is a desirable property in programming languages to not have overlapping features, because people will always be confused about when to use which (the classic example being pointers vs. references in C++).
  - gpderetta 11y ago
    One advantage is that the protected code will be syntax and typechecked even if it is "compiled" out. That will make it less likely to bitrot.
    - thealistra 11y ago
      Yeah it's hard to keep exponentially many code configurations that may compile together. It's hard to support in an IDE. Where a variable works nicely
dilap 11y ago
preprocessor tricks are cute, but there's definitely something to be said for staying completely w/in the language -- I've really come to appreciate this using Go, where I get incredible auto-formatting, rename refactor, and source introspection tools that would not be possible if a preprocessor were standard-issue. (Of course, Java people have been saying something similar for a long time, but I never could get into it, 'cuz of a bunch of other stuff, like the IDE-centric culture & the language itself)
- generic_user 11y ago
  > but there's definitely something to be said for staying completely w/in the language The C Pre Processor is defined in the ISO C standard. In order for any implementation to call it self a normative conforming C implementation I has to include a pre processor to spec. The Pre Processor is part of the ISO C language. > auto-formatting, rename refactor, source introspection tools All of those things are had quite easily with C. Either as IDE/Editor features or with separate tools such as Clang Complete, Valgrind and many others.
  - dilap 11y ago
    spent a long time w/ c and c++, never found tools anywhere near as good as what i've got now for go. maybe/probably not impossible, but a lot harder in practice. i have no personal experience, but people that seem to know what they're talking about say a big reason is the preprocessor makes life a lot harder. (and other stuff too, of course, like not having build semantics built into the language, and, for c++, just insane complexity in general.) obviously the preprocessor is well-defined and standardized, but it still: operates on a totally different semantic level. it really is like two entirely different languages pasted together.
    - generic_user 11y ago
      Would you mind listing a few tools you use with go? I do not have much exposure to go but from what I have seen there is a nice set of introspection libraries. are you talking about tools that use these? A final note, real time semantic checking of multiple expansion macros has been solved for quite a few years now and is in most IDE's and even in Vim and Emacs. Semantic analysis is done in the comelier, LLVM/Clang lib has given rise to a substantial set of tools that are now quite widely used and solve most of the problems. And I believe C++17 with concepts is also going to have a dramatic effect on complexity and readability of template error messages.
int0x80 11y ago
Nothing usually prevents you using the preprocesor and the running your code through cpp before running/compiling in most languages.

marvy 11y ago

There's no need to worry about a runtime check. Let DEBUG be a compile time constant, and the optimizer will remove the check. C++ seems to be (very) slowly moving in the direction of using the whole language at compile time: see how constexpr has been getting better. I doubt it will ever get anywhere near what lisp lets you do though, and in those cases the preprocessor sure does help at least partially fill the gap. This is my favorite explanation of the technique you linked to: http://journal.stuffwithstuff.com/2012/01/24/higher-order-macros-in-c/ http://journal.stuffwithstuff.com/2012/01/24/higher-order-ma...

nkurz 11y ago
Let DEBUG be a compile time constant, and the optimizer will remove the check. What do you feel is gained with "const int DEBUG" over "#define DEBUG"? While most compilers will do what you say most of the time, I haven't encountered a significant downside to the macro approach. I also like that I can have a makefile where "make debug" adds "-DDEBUG" to the compiler command line and appends "_debug" to the executable name. With the const approach, is there an easy way to automatically generate both debug and production executables?
- majewsky 11y ago
  I guess the argument is orthogonality. It is a desirable property in programming languages to not have overlapping features, because people will always be confused about when to use which (the classic example being pointers vs. references in C++).
- gpderetta 11y ago
  One advantage is that the protected code will be syntax and typechecked even if it is "compiled" out. That will make it less likely to bitrot.
  - thealistra 11y ago
    Yeah it's hard to keep exponentially many code configurations that may compile together. It's hard to support in an IDE. Where a variable works nicely

dilap 11y ago

preprocessor tricks are cute, but there's definitely something to be said for staying completely w/in the language -- I've really come to appreciate this using Go, where I get incredible auto-formatting, rename refactor, and source introspection tools that would not be possible if a preprocessor were standard-issue. (Of course, Java people have been saying something similar for a long time, but I never could get into it, 'cuz of a bunch of other stuff, like the IDE-centric culture & the language itself)

generic_user 11y ago
> but there's definitely something to be said for staying completely w/in the language The C Pre Processor is defined in the ISO C standard. In order for any implementation to call it self a normative conforming C implementation I has to include a pre processor to spec. The Pre Processor is part of the ISO C language. > auto-formatting, rename refactor, source introspection tools All of those things are had quite easily with C. Either as IDE/Editor features or with separate tools such as Clang Complete, Valgrind and many others.
- dilap 11y ago
  spent a long time w/ c and c++, never found tools anywhere near as good as what i've got now for go. maybe/probably not impossible, but a lot harder in practice. i have no personal experience, but people that seem to know what they're talking about say a big reason is the preprocessor makes life a lot harder. (and other stuff too, of course, like not having build semantics built into the language, and, for c++, just insane complexity in general.) obviously the preprocessor is well-defined and standardized, but it still: operates on a totally different semantic level. it really is like two entirely different languages pasted together.
  - generic_user 11y ago
    Would you mind listing a few tools you use with go? I do not have much exposure to go but from what I have seen there is a nice set of introspection libraries. are you talking about tools that use these? A final note, real time semantic checking of multiple expansion macros has been solved for quite a few years now and is in most IDE's and even in Vim and Emacs. Semantic analysis is done in the comelier, LLVM/Clang lib has given rise to a substantial set of tools that are now quite widely used and solve most of the problems. And I believe C++17 with concepts is also going to have a dramatic effect on complexity and readability of template error messages.

int0x80 11y ago

Nothing usually prevents you using the preprocesor and the running your code through cpp before running/compiling in most languages.