4 ms·

Agree except the last example - the clarity of intent that you want a conditional compilation is lost. Also, non-optimized debug builds are affected.

by zerr 5y ago

CamperBob2 5y ago
I think it was RMS who argued that conditional compilation should be considered harmful in general. Code that you put in an inactive #if(def) block will not be maintained, and is basically guaranteed to rot. If it's needed in the future, it'll likely have to be rewritten from scratch. According to this stance, any code that's suppressed by the C preprocessor should either be written in an if {} statement so that it will at least continue to compile as the surrounding code changes, or be replaced with comments describing what it does (or did), if it's important enough to keep track of. Can't really think of many good counterarguments to this. Machine dependence might be one, but then you could argue that the preprocessor is being used to cover up for an inadequate HAL.
- zerr 5y ago
  When it comes to cross-platform code, you build for several platforms, so the block is active (for particular platforms) and maintained.
WalterBright 5y ago
> clarity of intent Conditional compilation is an optimization, not a semantic intent. > non-optimized debug builds are affected The code size will be larger. Doesn't matter.
- jjnoakes 5y ago
  > Conditional compilation is an optimization, not a semantic intent. Why can't it have semantic intent? I frequently use it for cross-platform adjustments, and those don't usually compile on the defined-away platform.
  - WalterBright 5y ago
    > those don't usually compile on the defined-away platform Then you're doing it wrong :-/ All these can be made to work. P.S. compiling successfully is not the same thing as linking successfully. Think stubs and deciding which files to link together.
    - zerr 5y ago
      Making it clear in the code itself that something is platform specific is useful as well. Also, I'd say such stubs and extra files would clutter the project.
      - WalterBright 5y ago
        I tried it your way for years. It's common practice in the industry. I have written and seen plenty of rats' nests of #if and #ifdef snarls so bad one cannot figure out what is being compiled and what isn't without running a just-the-preprocessor pass. It will often #if on the wrong condition, like operating system when it's a CPU dependency. Rewriting it the way I suggest tends to force a cleanup of all that. You'll like the results. BTW, if you want to try transitioning to the next level, try getting rid of all the `if` statements, too!
    - jjnoakes 5y ago
      They can be made to work by introducing stubs for every os/arch/compiler/dependency I support, but that's way more work for dubious gain. And who is to say I'm doing it wrong? Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. And if it happens to be well-organized and works as is, there is no problem.
      - WalterBright 5y ago
        > that's way more work for dubious gain Oh, have I heard that before. Here's what happens, over the years, to such code: 1. #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature. 2. Overly complex #if expressions, that steadily get worse. 3. Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q. 4. People having no idea what #defines to set on the command line, nor what the ones that are set are doing (if anything). 4. People having no idea how to fold in support for new configurations. 5. Code will #ifdef on predefined macros that have little or no documentation on what they're for or under exactly what circumstances they are set. If the writer even bothered to research that. gcc predefines what, 400 macros? > Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. Jyust yew wite, 'enry 'iggins, jyust yew wite!

Agree except the last example - the clarity of intent that you want a conditional compilation is lost. Also, non-optimized debug builds are affected.

by zerr 5y ago

Agree except the last example - the clarity of intent that you want a conditional compilation is lost. Also, non-optimized debug builds are affected.

CamperBob2 5y ago

I think it was RMS who argued that conditional compilation should be considered harmful in general. Code that you put in an inactive #if(def) block will not be maintained, and is basically guaranteed to rot. If it's needed in the future, it'll likely have to be rewritten from scratch. According to this stance, any code that's suppressed by the C preprocessor should either be written in an if {} statement so that it will at least continue to compile as the surrounding code changes, or be replaced with comments describing what it does (or did), if it's important enough to keep track of. Can't really think of many good counterarguments to this. Machine dependence might be one, but then you could argue that the preprocessor is being used to cover up for an inadequate HAL.

zerr 5y ago
When it comes to cross-platform code, you build for several platforms, so the block is active (for particular platforms) and maintained.

WalterBright 5y ago

> clarity of intent Conditional compilation is an optimization, not a semantic intent. > non-optimized debug builds are affected The code size will be larger. Doesn't matter.

jjnoakes 5y ago
> Conditional compilation is an optimization, not a semantic intent. Why can't it have semantic intent? I frequently use it for cross-platform adjustments, and those don't usually compile on the defined-away platform.
- WalterBright 5y ago
  > those don't usually compile on the defined-away platform Then you're doing it wrong :-/ All these can be made to work. P.S. compiling successfully is not the same thing as linking successfully. Think stubs and deciding which files to link together.
  - zerr 5y ago
    Making it clear in the code itself that something is platform specific is useful as well. Also, I'd say such stubs and extra files would clutter the project.
    - WalterBright 5y ago
      I tried it your way for years. It's common practice in the industry. I have written and seen plenty of rats' nests of #if and #ifdef snarls so bad one cannot figure out what is being compiled and what isn't without running a just-the-preprocessor pass. It will often #if on the wrong condition, like operating system when it's a CPU dependency. Rewriting it the way I suggest tends to force a cleanup of all that. You'll like the results. BTW, if you want to try transitioning to the next level, try getting rid of all the `if` statements, too!
  - jjnoakes 5y ago
    They can be made to work by introducing stubs for every os/arch/compiler/dependency I support, but that's way more work for dubious gain. And who is to say I'm doing it wrong? Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. And if it happens to be well-organized and works as is, there is no problem.
    - WalterBright 5y ago
      > that's way more work for dubious gain Oh, have I heard that before. Here's what happens, over the years, to such code: 1. #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature. 2. Overly complex #if expressions, that steadily get worse. 3. Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q. 4. People having no idea what #defines to set on the command line, nor what the ones that are set are doing (if anything). 4. People having no idea how to fold in support for new configurations. 5. Code will #ifdef on predefined macros that have little or no documentation on what they're for or under exactly what circumstances they are set. If the writer even bothered to research that. gcc predefines what, 400 macros? > Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. Jyust yew wite, 'enry 'iggins, jyust yew wite!