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.
Conditional compilation is an optimization, not a semantic intent.
> non-optimized debug builds are affected
The code size will be larger. Doesn't matter.
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.
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.
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!
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.
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!
Over how many years? Some of my projects are 30+ years old and support a few dozen combinations of OSes, compilers, and architectures, and the method I described hasn't led to a rat's nest yet.
> #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature
Sure, same thing happens when you decide whether to compile in your stubs or not. But if I make a mistake, the code usually won't compile on the configuration in question; if you make a similar mistake, it'll compile with your stub, it might even link, but you'll get odd runtime behavior. Sounds worse.
> Overly complex #if expressions, that steadily get worse
All code gets worse over time and bit rots if you don't maintain it, I don't see things necessarily worse in this area.
> Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q
If you aren't testing on tier one configurations, they shouldn't be tier one. And if a tier three configuration breaks when you do finally get around to testing it, it's tier three, so it gets fixed when it can be and there's no problem. Similar to normal code, I'd say.
> People having no idea what #defines to set on the command line, nor what the ones that are set are doing (if anything) > People having no idea how to fold in support for new configurations
These problems exist for normal code as well. Someone has to own the build configurations, and they have to be maintained, like anything else.
> 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?
We only use a handful, and they are fairly well documented. But even if they weren't, since the code works on all tier one platforms, we'd know if something was changed out from underneath us because it was underspecified or accidentally relied upon.
But again the same can happen with normal code and system headers, compiler extensions, etc - I don't see why pre-processor macros have to be singled out here.
> Jyust yew wite, 'enry 'iggins, jyust yew wite!
How long?
The optimizer will delete bar() if FOO is a manifest constant that is not 3.
extern void bar();
void my_bar_class_type::bar(my_bar_type<my_bar_type_2>::my_bar_inside_type paramater);
myObject->bar(mySecondObject.getWhatever());
It is a terrible thing. It's possible to do without them, and you'll like your code better. Your symbolic debugger and syntax directed editor will work properly. The poor schlub who has to fix the bugs in your code after you leave will be grateful. Your spouse will be happy and your children will prosper.
For example,
replace with: The compiler will inline it for you. There's no penalty. Replace with: or: Replace: with: The optimizer will delete bar() if FOO is a manifest constant that is not 3.