-
Hello,
I will try to do my best explaining my question.
In a case structure like this one:
switch(Value){
case 1:
OutputValue= "CaseValue" + 275;
break;
case 2:
OutputValue= "CaseValue" + 275;
break;
case 3:
OutputValue= "CaseValue" + 275;
break;
}
Would it be possible to refer to each case value inside the case statement without writing manually the value?
On the example, the three possible results would be 276, 277 and 278.
The example is very simple, but I have code where I use several times the "CaseValue" inside the statement and I repeat the structure for several Case values. So using a reference to the value would allow to copy-paste the structure without having to modify each value manually and maybe avoiding human mistakes
Thank you in advance for any help
-
Never mind.
I realized how stupid the question is after posting it. Just use
switch(Value){
case 1:
OutputValue= Value + 275;
break;
case 2:
OutputValue= Value + 275;
break;
case 3:
OutputValue= Value + 275;
break;
}
:palm:
-
Oh for %DEITY%'s sake, if the case blocks in question are actually identical use fallthrough rather than copy/pasta code!
switch(Value){
case 1:
case 2:
case 3:
OutputValue= Value + 275;
break;
// Other case blocks that require separate handling
}
-
Finally, if you can tolerate a GCC specific departure from ANSI C, you can use case ranges:
switch(Value){
case 1 ... 3:
OutputValue= Value + 275;
break;
// Other case blocks that require separate handling
}
which tidies it up considerably. See: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
N.B. the ellipses indicating a range should always be separated by whitespace from the range limits.
-
Sometimes the mot obvious is not obvious:
if (Value >= 1 && Value <= 3) {
OutputValue = Value + 275;
}
-
Finally, if you can tolerate a GCC specific departure from ANSI C, you can use case ranges:
switch(Value){
case 1 ... 3:
OutputValue= Value + 275;
break;
// Other case blocks that require separate handling
}
which tidies it up considerably. See: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
N.B. the ellipses indicating a range should always be separated by whitespace from the range limits.
Nice one! I always wondered if it could be done that way instead piling up "cases".
-
Finally, if you can tolerate a GCC specific departure from ANSI C, you can use case ranges:
switch(Value){
case 1 ... 3:
OutputValue= Value + 275;
break;
// Other case blocks that require separate handling
}
which tidies it up considerably. See: https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
N.B. the ellipses indicating a range should always be separated by whitespace from the range limits.
Nice one! I always wondered if it could be done that way instead piling up "cases".
Only in gcc, and compilers that try to be compatible with gcc, such as Clang.
-
And, if I'm using C, there's no way I would use such a non-standard feature. But that's just me.
-
If its even remotely possible that you will need portability, then avoiding the use of any proprietary extensions is the *ONLY* sane thing to do. OTOH if your code is already so closely tied to a platform for which only GCC based compilers are available that porting it will be a royal PITA, and reuse of significant portions elsewhere is unlikely, you've got very little to loose and quite a bit of clarity of expression to gain, by using one more proprietary GCC extension to ANSI/ISO C.
-
If you are writing low level C for microcontrollers, it could be that (compiler) portability is not your biggest concern.
I still do not like non standards. Because of "portability of maintainer". I would like my code to be interpreted by people that know only basic ANSI C.
My colleagues at work are always impressed because I use so few features of C++, and my code is extremely easy to understand, being typically faster as other code.
I also keep away of no POSIX extension in linux scripts.
-
Yep, and, there's a definite difference between extensions that modify the standard behavior/syntax/... of existing language constructs, and extensions that add constructs or attributes that are simply not defined in the standard. While both are non-portable, the first category is far worse IMO.
The only extensions I ever use (for low-level stuff) are just attributes, which are not even breaking the standard, they are simply beyond its scope, and attributes will usually not make static analysis tools (at least decent and decently recent ones) go bonkers.