7 ms·
> Data in general is never const On MCUs const data (along with the whole .text section) is stored in flash which is very much const. That's also why you want
by pantalaimon 5y ago
> Data in general is never const
On MCUs const data (along with the whole .text section) is stored in flash which is very much const.
That's also why you want to use const whenever possible so you are not wasting precious RAM.
- jstimpfle 5y agoAlready changed that to "is rarely truly constant". Also, that flash can be written, even if not during the lifetime of a process. > That's also why you want to use const whenever possible so you are not wasting precious RAM. My point is to not overthink placement of "const" in function parameters, local variables, etc. Because those don't make any difference to the compiled output. I already mentioned string literals as one type of "reasonably constant" data, and of course any other thing that goes in the .rodata section (such as globally declared const variables) is as much constant. To wrap it up, the "const" keyword totally makes sense in global declarations to make them go to .rodata. Using const for type-checking purposes can get quirky on the other hand.
- sgtnoodle 5y agoMost MCUs can mutate their flash, though, and most large embedded projects have one or two weird features that depend on mutating flash and then accessing it as const data. Also, Harvard architectures like AVR have different address spaces for flash vs. ram, so const variables still end up copied into RAM unless you qualify the variable types with non-standard decorators. Being able to explicitly tell the compiler, "you can and should compile this out" seems like a good thing?