3 ms·

The article does not seem to mention any uses of conditional compilation outside of portability. But consider the most common case: debug and release versions o

The article does not seem to mention any uses of conditional compilation outside of portability. But consider the most common case: debug and release versions of the same program. You want the extra checks and diagnostics in the debug version and fastest code in the release. Using assert() will only get you so far because you might need to compute values to assert on and if those require function calls then the calls will still be there when asserts are eliminated in the release. And if you want additional room in your data structures to store debug info then assert() is of no use.

eesmith 8y ago
When you say "the most common case", I assume you mean "the most common case now", and not in 1992 when this paper was written. The abstract does start "We believe that a C programmer's impulse to use #ifdef in an attempt at portability is usually a mistake" so it's fair to assume that they were not trying to cover other uses of #ifdef. That said, your points weren't completely ignored. Page 193 mentions #ifdef use in debug builds in the text starting "An optional feature such as debugging assistance ...". The part about "additional room in your data structures" follows under the guideline "Such declarations, in turn, preferably should be confined to header (.h) files, to minimize the temptation to introduce #ifdef into main-line code".
Annatar 8y ago
“Debug” and “Release” only pertains to Windows. You are always supposed to build with -g on UNIX and UNIX like operating systems because besides a few miliseconds of startup time, including the source code into the binary doesn’t affect anything but file size. The runtime linker skips those sections and links only code and data into memory, but the source code is there if you load it into the debugger. Kernel engineers taught me this.
- pandaman 8y ago
  There are much more differences between debug and release than having debug info included in the executable so your reasoning makes little sense. Many people, for example, build games for PS4, which runs a FreeBSD Unix-like OS, unawares that their debug and release builds only pertain to Windows...

eesmith 8y ago

When you say "the most common case", I assume you mean "the most common case now", and not in 1992 when this paper was written. The abstract does start "We believe that a C programmer's impulse to use #ifdef in an attempt at portability is usually a mistake" so it's fair to assume that they were not trying to cover other uses of #ifdef. That said, your points weren't completely ignored. Page 193 mentions #ifdef use in debug builds in the text starting "An optional feature such as debugging assistance ...". The part about "additional room in your data structures" follows under the guideline "Such declarations, in turn, preferably should be confined to header (.h) files, to minimize the temptation to introduce #ifdef into main-line code".

Annatar 8y ago

“Debug” and “Release” only pertains to Windows. You are always supposed to build with -g on UNIX and UNIX like operating systems because besides a few miliseconds of startup time, including the source code into the binary doesn’t affect anything but file size. The runtime linker skips those sections and links only code and data into memory, but the source code is there if you load it into the debugger. Kernel engineers taught me this.

pandaman 8y ago
There are much more differences between debug and release than having debug info included in the executable so your reasoning makes little sense. Many people, for example, build games for PS4, which runs a FreeBSD Unix-like OS, unawares that their debug and release builds only pertain to Windows...