I use const all over the place, but no so much to make the code faster as to eliminate potential stupid mistakes.
Why Const Doesn't Make C Code Faster
101–110 of 197 posts
Re: Why Const Doesn't Make C Code Faster
#102The key difference between `const` and the `register` and `inline` keywords is that, despite all of them often flagging optimisations that the compiler can often work out anyway, `const` still aids human comprehension by declaring constraints, whereas the latter two do not. It seems that interprocedure optimisations in modern compilers make a lot of const-by-reference optimisations apply even when the code is mutable…
Local constant stack values surely can be completely deterministically verified as such by the optimiser even without the `const` modifier.
Only if their address doesn't escape.
Re: Why Const Doesn't Make C Code Faster
#103gcc has some attributes to help with that, for example try __attribute__((pure)) on funcs that will always return the same thing for the same inputs (given the same global state) and do not modify said input or state (and thus can be called more or fewer times than programmer wrote). Usually gcc will be quite aggressive with optimizations if you use that. For even more aggressiveness, try __attribute__((const)) which…
> try __attribute__((const)) which tells it that the func accesses NOTHING but the params, not even global vars
And it doesn’t do anything unintended if you’re lying to it by accessing the global state that you know to be constant?
Re: Why Const Doesn't Make C Code Faster
#104I once had a very stubborn intern who decided to add as much const as he could in our codebase. What followed was a heated discussion and I did a global replace of const by nothing. The main problem with const is that it's ugly, it's viral and it does not add any value to the code. And I know all the supposedly good things about this, but I never found any real usage in practice.
You should fire yourself. Seriously.
Understanding which object parameters to a function are inputs and which ones are modified is key information about the behavior of a function. It's omission requires devs to divine the intent from the name and hope that every previous dev was a good citizen w.r.t keeping function names accurate to intent.
Finding and replace const with empty is the moral equivalent of replacing all the types of parameters with void*. After all, types are viral and ugly too.
I really hope that intern found a better place to work than your company.
Re: Why Const Doesn't Make C Code Faster
#105gcc has some attributes to help with that, for example try __attribute__((pure)) on funcs that will always return the same thing for the same inputs (given the same global state) and do not modify said input or state (and thus can be called more or fewer times than programmer wrote). Usually gcc will be quite aggressive with optimizations if you use that. For even more aggressiveness, try __attribute__((const)) which…
> try __attribute__((const)) which tells it that the func accesses NOTHING but the params, not even global vars And it doesn’t do anything unintended if you’re lying to it by accessing the global state that you know to be constant?
It will only assume that it is safe to skip multiple calls to this function with the same parameters, safe to generate extra calls that you did not write, and safe to skip the entire call if the return value is ignored
Re: Why Const Doesn't Make C Code Faster
#106It's true that, as demonstrated, const-qualifying your pointer arguments is very unlikely to allow any optimisations on its own.
However, const-qualifying your pointer arguments where the pointed-to object isn't changed is what allows you to make more liberal use of const-qualified declarations, and as also demonstrated by the article, those in turn do allow some optimisations.
Additionally, there is some safety on the table: if your C program makes use of pointers to structures full of function pointers to implement polymorphism, making those pointers const-qualified allows your underlying structures full of function pointers to be declared const, which in turn allows them to be stored in hardware-enforced read-only memory.
As a side note, I've often thought that block-scope variables declared const and whose address is never taken should be automatically made static.
Re: Why Const Doesn't Make C Code Faster
#107Earlier quoted context omitted.
BINGO!!! The pointer is constant, not the item being pointed to. Since you’re dereferencing the pointer, i.e. accessing the non-const bits, the compiler must reload.
The examples in the articles are non-constant pointers to constant data. If you want to declare the pointer itself const, you need to do it after the asterisk. const int* const instead of const int*
Exactly. const int* is a non-const pointer to a const int; int* const is a const pointer to a non-const int. So I’m pretty confused by the claims.
Maybe the compiler will happily let you modify the dereferenced const int* (undefined behavior), wouldn’t try it now, but that’s not what the signature promises.
Edit: Thought about it more and read some other comments. Now it makes sense.
Re: Why Const Doesn't Make C Code Faster
#108The key difference between `const` and the `register` and `inline` keywords is that, despite all of them often flagging optimisations that the compiler can often work out anyway, `const` still aids human comprehension by declaring constraints, whereas the latter two do not. It seems that interprocedure optimisations in modern compilers make a lot of const-by-reference optimisations apply even when the code is mutable…
While specifying inline alone is useless for optimization, the inline specifier is important for another type of optimization: putting a function in a header file. If you put a function in a header file and don't mark it inline, that tends to be undefined behavior because it tends to violate the One Definition Rule, (both C and C++).
Re: Why Const Doesn't Make C Code Faster
#109Surprised no one has mentioned what the author of C, Dennis Ritchie, said about the addition of "const" to the language.
Re: Why Const Doesn't Make C Code Faster
#110Earlier quoted context omitted.
The examples in the articles are non-constant pointers to constant data. If you want to declare the pointer itself const, you need to do it after the asterisk. const int* const instead of const int*
Exactly. const int* is a non-const pointer to a const int; int* const is a const pointer to a non-const int. So I’m pretty confused by the claims. Maybe the compiler will happily let you modify the dereferenced const int* (undefined behavior), wouldn’t try it now, but that’s not what the signature promises. Edit: Thought about it more and read some other comments. Now it makes sense.
If the initial object itself isn't const, then merely declaring the function parameter as a pointer to const won't guarantee that some other thread of execution won't change the value under your nose. Or if you have multiple pointer parameters, they can alias each other.
Indirection in C and C++ is a mess, but at least C has the "restrict" keyword. Best to program with value types whenever you can, and use pointers and references when you must.