Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the >combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
Il 13/03/2025 16:44, pozz ha scritto:
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the
combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
You're right, a real example is better to define my problem.
I have a project that can be compiled in different ways, depending on
the final product model (it's an embedded platform, it's a material
device).
I have three models with different characteristics: MODEL_A, MODEL_B, MODEL_C. Three different builds that are managed at compile time by
defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
For each model, I could have a different features set. FEATURE_1,
FUTURE_2, FUTURE_3, ...
#if MODEL == MODEL_A
# define FEATURE_1 1
# define FEATURE_2 0
# define FEATURE_3 0
#elif MODEL == MODEL_B
# define FEATURE_1 0
# define FEATURE_2 1
# define FEATURE_3 0
#elif MODEL == MODEL_C
# define FEATURE_1 1
# define FEATURE_2 1
# define FEATURE_3 1
#endif
Now, on the full-featured model (MODEL_C) I could write:
if (key == 1) {
...
} else if (key == 2) {
...
} else if (key == 3) {
...
} else {
...
}
However, for MODEL_A I should have:
if (key == 1) {
...
} else {
...
}
For MODEL_B I should have:
if (key == 2) {
...
} else {
...
}
This is the scenario.
I thought using if(0) or if(1), but many times I receive some warnings
from the compiler (condition is always true or condition is always false).
Il 13/03/2025 16:44, pozz ha scritto:
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the
combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
You're right, a real example is better to define my problem.
I have a project that can be compiled in different ways, depending on
the final product model (it's an embedded platform, it's a material
device).
I have three models with different characteristics: MODEL_A, MODEL_B, MODEL_C. Three different builds that are managed at compile time by
defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
For each model, I could have a different features set. FEATURE_1,
FUTURE_2, FUTURE_3, ...
#if MODEL == MODEL_A
# define FEATURE_1 1
# define FEATURE_2 0
# define FEATURE_3 0
#elif MODEL == MODEL_B
# define FEATURE_1 0
# define FEATURE_2 1
# define FEATURE_3 0
#elif MODEL == MODEL_C
# define FEATURE_1 1
# define FEATURE_2 1
# define FEATURE_3 1
#endif
On 3/13/2025 4:37 PM, Tim Rentsch wrote:
pozz <[email protected]> writes:
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the
combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
if ( ..bypass all further tests.. ) {
// for a "skip all conditional segments" case (if needed)
...
#if TEST_1
} else if (cond1) {
...
#endif
#if TEST_2
} else if (cond2) {
...
#endif
#if TEST_3
} else if (cond3) {
...
#endif
} else {
// for a "no conditional segment" ran case (if needed)
...
}
>
Having said that, it's hard to imagine a scenario where doing
something like this is the best way to solve the higher level
problem. It is almost certainly better to rethink the reasoning
that resulted in choosing this scheme, and find a way to avoid it.
It is code that must run on several platforms.
Il 13/03/2025 16:44, pozz ha scritto:
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All
the combinations are possible: only the first, only the second, only
the third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
You're right, a real example is better to define my problem.
I have a project that can be compiled in different ways, depending on
the final product model (it's an embedded platform, it's a material
device).
I have three models with different characteristics: MODEL_A, MODEL_B, MODEL_C. Three different builds that are managed at compile time by
defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
For each model, I could have a different features set. FEATURE_1,
FUTURE_2, FUTURE_3, ...
#if MODEL == MODEL_A
# define FEATURE_1 1
# define FEATURE_2 0
# define FEATURE_3 0
#elif MODEL == MODEL_B
# define FEATURE_1 0
# define FEATURE_2 1
# define FEATURE_3 0
#elif MODEL == MODEL_C
# define FEATURE_1 1
# define FEATURE_2 1
# define FEATURE_3 1
#endif
Now, on the full-featured model (MODEL_C) I could write:
if (key == 1) {
...
} else if (key == 2) {
...
} else if (key == 3) {
...
} else {
...
}
However, for MODEL_A I should have:
if (key == 1) {
...
} else {
...
}
For MODEL_B I should have:
if (key == 2) {
...
} else {
...
}
This is the scenario.
I thought using if(0) or if(1), but many times I receive some
warnings from the compiler (condition is always true or condition
is always false).
for( int just_once = 1; just_once; just_once = 0 ){
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
Tim Rentsch <[email protected]> writes:
Richard Harnden <[email protected]d> writes:
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
In fact using do/while(0) is what I first wrote. But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error." I recently ran across a set of coding standard
rules that included these rules: not just /some/ warning
conditions, but ALL warning conditions. I still don't know
if they were literally serious. (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)
I've worked under such coding standards. Perhaps surprisingly, I
haven't found them to be terribly inconvenient. I rarely ran into
a warning that was inordinately difficult to avoid. I can see that
"clang -Weverything" would cause problems.
The most common inconvenience was that if I experimentally commented
out some code, and it caused some variable not to be referenced,
the build would fail. (I could just add `(void)foo;` to avoid that.)
To be clear, this was not code that I intended to commit.
I can imagine that there could be problems if a newer version of the
compiler produced new warnings, but we didn't often change compilers.
(In one obscure case, I wrote a wrapper script that could be
installed in $PATH as "gcc" that would invoke the real gcc and
filter out a particular warning. The wrapper was necessary due to
the behavior of a build script, not to an explicit coding standard.)
Tim Rentsch <[email protected]> writes:
Richard Harnden <[email protected]d> writes:
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
In fact using do/while(0) is what I first wrote. But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error." I recently ran across a set of coding standard
rules that included these rules: not just /some/ warning
conditions, but ALL warning conditions. I still don't know
if they were literally serious. (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)
I've worked under such coding standards.
Perhaps surprisingly, I
haven't found them to be terribly inconvenient. I rarely ran into
a warning that was inordinately difficult to avoid. I can see that
"clang -Weverything" would cause problems.
The most common inconvenience was that if I experimentally commented
out some code, and it caused some variable not to be referenced,
the build would fail. (I could just add `(void)foo;` to avoid that.)
To be clear, this was not code that I intended to commit.
I can imagine that there could be problems if a newer version of the
compiler produced new warnings, but we didn't often change compilers.
(In one obscure case, I wrote a wrapper script that could be
installed in $PATH as "gcc" that would invoke the real gcc and
filter out a particular warning. The wrapper was necessary due to
the behavior of a build script, not to an explicit coding standard.)
On 14/03/2025 21:10, Keith Thompson wrote:
Tim Rentsch <[email protected]> writes:
Richard Harnden <[email protected]d> writes:
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
In fact using do/while(0) is what I first wrote. But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
That would break a lot of macros :)
[...]
Hmm, clang with -Weverything is okay with:
do { ... } while (0);
But not with:
if ( 0 ) { ... }
But it's okay with:
if ( (0) ) { ... }
Il 13/03/2025 16:44, pozz ha scritto:
Consider this code:
if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}
I want to activate every single if with a macro preprocessor. All the
combinations are possible: only the first, only the second, only the
third, the first and second... and so on.
What's the best method to have a clean code that is always compiled
without errors?
You're right, a real example is better to define my problem.
I have a project that can be compiled in different ways, depending on
the final product model (it's an embedded platform, it's a material
device).
I have three models with different characteristics: MODEL_A, MODEL_B, MODEL_C. Three different builds that are managed at compile time by
defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
For each model, I could have a different features set. FEATURE_1,
FUTURE_2, FUTURE_3, ...
#if MODEL == MODEL_A
# define FEATURE_1 1
# define FEATURE_2 0
# define FEATURE_3 0
#elif MODEL == MODEL_B
# define FEATURE_1 0
# define FEATURE_2 1
# define FEATURE_3 0
#elif MODEL == MODEL_C
# define FEATURE_1 1
# define FEATURE_2 1
# define FEATURE_3 1
#endif
Now, on the full-featured model (MODEL_C) I could write:
if (key == 1) {
...
} else if (key == 2) {
...
} else if (key == 3) {
...
} else {
...
}
Any reason not to say ...
do {
...
} while (0);
... ?
Tim Rentsch <[email protected]> writes:
Keith Thompson <[email protected]> writes:
Tim Rentsch <[email protected]> writes:
It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error." I recently ran across a set of coding standard
rules that included these rules: not just /some/ warning
conditions, but ALL warning conditions. I still don't know
if they were literally serious. (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)
I've worked under such coding standards.
I'm guessing this comment is an overstatement, and that you have
worked with similar but not nearly as stringent coding standards.
The coding standard I was referring to above says "Compile with
all possible warnings active" (and then also says something about
addressing them).
Right, I didn't read closely enough. Some (non-maximal) set of warnings
were enabled, and any warnings that resulted were treated as fatal errors.
Keith Thompson <[email protected]> writes:
Tim Rentsch <[email protected]> writes:
Keith Thompson <[email protected]> writes:
Tim Rentsch <[email protected]> writes:
It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error." I recently ran across a set of coding standard
rules that included these rules: not just /some/ warning
conditions, but ALL warning conditions. I still don't know
if they were literally serious. (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)
I've worked under such coding standards.
I'm guessing this comment is an overstatement, and that you have
worked with similar but not nearly as stringent coding standards.
The coding standard I was referring to above says "Compile with
all possible warnings active" (and then also says something about
addressing them).
Right, I didn't read closely enough. Some (non-maximal) set of
warnings were enabled, and any warnings that resulted were treated
as fatal errors.
We build with -Wall. It's been quite successful for us and
hasn't resulted in significant effort to maintain (granted
as we switch to newer versions of the compiler suite, we
run into new warnings, but they're quite easy to address
either via code changes or #pragma).
The codebase runs well over two million SLOC and supports
gcc7 through gcc14.
Richard Harnden <[email protected]d> writes:
On 14/03/2025 21:10, Keith Thompson wrote:
Tim Rentsch <[email protected]> writes:
Richard Harnden <[email protected]d> writes:
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
In fact using do/while(0) is what I first wrote. But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
That would break a lot of macros :)
[...]
Hmm, clang with -Weverything is okay with:
do { ... } while (0);
But not with:
if ( 0 ) { ... }
But it's okay with:
if ( (0) ) { ... }
These examples illustrate why I have the reaction I do. That
plus the lack of clarity as to what the OP's actual requirements
are explains my decision to use a for() rather than do/while(0).
Tim Rentsch <[email protected]> writes:
Richard Harnden <[email protected]d> writes:
On 14/03/2025 16:44, Tim Rentsch wrote:
for( int just_once = 1; just_once; just_once = 0 ){
Any reason not to say ...
do {
...
} while (0);
... ?
In fact using do/while(0) is what I first wrote. But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error." I recently ran across a set of coding standard
rules that included these rules: not just /some/ warning
conditions, but ALL warning conditions. I still don't know
if they were literally serious. (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)
I've worked under such coding standards. Perhaps surprisingly, I
haven't found them to be terribly inconvenient. I rarely ran into
a warning that was inordinately difficult to avoid. I can see that
"clang -Weverything" would cause problems.
The most common inconvenience was that if I experimentally commented
out some code, and it caused some variable not to be referenced,
the build would fail. (I could just add `(void)foo;` to avoid that.)
To be clear, this was not code that I intended to commit.
I can imagine that there could be problems if a newer version of the
compiler produced new warnings, but we didn't often change compilers.
(In one obscure case, I wrote a wrapper script that could be
installed in $PATH as "gcc" that would invoke the real gcc and
filter out a particular warning. The wrapper was necessary due to
the behavior of a build script, not to an explicit coding standard.)
[email protected] (Scott Lurndal) writes:
Keith Thompson <[email protected]> writes:
We build with -Wall. It's been quite successful for us and
hasn't resulted in significant effort to maintain (granted
as we switch to newer versions of the compiler suite, we
run into new warnings, but they're quite easy to address
either via code changes or #pragma).
The codebase runs well over two million SLOC and supports
gcc7 through gcc14.
Can you say which new warnings have been addressed via #pragma
(which I assume effectively means selective disabling)?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:08:00 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,529 |