3 ms·

My advice is to not bother using const much. It's quirky since data that is "const" for one part of the code might not be for another. But no one has figured ou

My advice is to not bother using const much. It's quirky since data that is "const" for one part of the code might not be for another. But no one has figured out a way to represent such a constness-transition. You can find this issue with APIs like "strstr()" for example. And IIRC Dennis Ritchie himself raised these concerns when const was conceived. The deeper issue I think is that const should be an attribute of the _code_ (as in, "I won't modify this data"), not of the data. Data is rarely truly constant (RAM cells are obviously writeable). I use "const" mostly in "const char *" (for string-literals which are pointers to "reasonably const" memory, i.e. read-only mapped memory), and sometimes for function parameters to indicate that the function does not write through the pointer, but as in "strstr()" example this quickly gets quirky. Note that for this simple example you can work around if you take a const-pointer and return an index instead. Summary: Be practical, don't overthink it.

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 ago
  Already 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 ago
  Most 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?
klyrs 5y ago
I use const frequently, because it helps prevent bugs. When something erroneously mutates immutable data, I want to know that as soon as possible, not months down the road when a corner case gets uncovered. One obvious example of this is thread-safety: you can't write to a const, so the compiler prevents you from introducing data races. And yeah, sometimes it's annoying write const and non-const versions of the same code. But in my experience, those situations are quite rare and can often be factored out to one-liners; typically, only providing a const version is sufficient.

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 ago
Already 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 ago
Most 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?

klyrs 5y ago

I use const frequently, because it helps prevent bugs. When something erroneously mutates immutable data, I want to know that as soon as possible, not months down the road when a corner case gets uncovered. One obvious example of this is thread-safety: you can't write to a const, so the compiler prevents you from introducing data races. And yeah, sometimes it's annoying write const and non-const versions of the same code. But in my experience, those situations are quite rare and can often be factored out to one-liners; typically, only providing a const version is sufficient.