Computing > Programming

C Programming - Refer to switch structure value inside each case statement

<< < (3/3)

Ian.M:
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. 

esepecesito:
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.

evb149:
Another possibly serious problem with using non standard (ISO C++/C) language extensions that are specific to a given
toolchain or compiler is that they may not be supported by CASE tools you'd care to use -- e.g.
1: syntax checking / auto-completing et. al. IDEs / editors
2: static analysis / linter tools

(1) is highly annoying if it causes your editor / IDE to fail to 'parse' the code properly and in that case it may either
flag errors that don't really exist or fail to find errors that do exist; those effects may not be localized to a small area of code --
e.g. if you have a non standard construct in some header file or at some point in a module it could "poison" the parsing of the entire module code subsequent to its appearance.

Actually that's also a problem if you use a more modern construct (e.g. C/C++ 17/14/11) than your editor / IDE parses then it may consider lots of code in your module as erroneously erroneous.

(2) is highly annoying since it can render your static analysis / linting useless for lots of "unrelated" code in your modules.
For this reason I consider it harmful if MCU embedded toolchains don't have some way to "stub out" MCU specific
things like macros, register names, etc. so they can be made to appear to be standard ISO C/C++ variables / symbols
e.g. "
extern "C" {
extern uint8_t * const  UART1_THR;
}

...just so that you can run an ISO C/C++ static analyzer on your MCU code and have it pass without warnings despite a lot
of MCU specific code and constructs present.





--- Quote from: Ian.M on July 30, 2021, 06:46:48 pm ---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.

--- End quote ---

SiliconWizard:
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.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version