4 ms·
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 m
by 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 agoLet 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 agoI 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 agoOne 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 agoYeah 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