5 ms·

Const does make C go faster, just not in most of the places you see it used. For const to help, the object itself needs to be defined const. Just taking a `con

Const does make C go faster, just not in most of the places you see it used. For const to help, the object itself needs to be defined const. Just taking a `const object * ` (or `const object&` in C++) doesn't help you determine the constness of the underlying object, and that usually accounts for the majority of const usage by volume. Limiting the scope to of actual const definitions, it can help a lot, but only in cases where the compiler couldn't move that anyways. So local variable const definitions rarely help, because the compiler can often already prove they are const by inspection (but they can help if the variable escapes). They are useful especially for global variables (and moral equivalents, like static class members in C++), since the compiler cannot prove by examining only the current TU whether the variable is unmodified (and it is a hard problem even if the whole program can be inspected), so const is a useful promise there.

taylodl 7y ago
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.
- bstamour 7y ago
  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*
  - oefrha 7y ago
    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.
    - bstamour 7y ago
      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.
      - rrss 7y ago
        > won't guarantee that some other thread of execution won't change the value under your nose My understanding is that compilers can always assume that there is no other thread involved, which (part of) why C11 atomics are necessary. Is that not the case?
        H8crilA 7y ago
        Yup, it's a data race (and therefore UB) to access the same memory from two different threads without synchronizing instructions (like mutexes, thread start/join, atomics). It is allowed to concurrently read from const regions. But not concurrently read and write, and definitely not concurrently write.
        alexlarsson 7y ago
        Yes, but it can't assume any random function call it does doesn't use a different pointer to the same object which is not const. So, even if you don't cast const to non-const pointers you can run into the const value changing.
        bstamour 7y ago
        Concrete example: void foo(const int* const p1, int* const p2) { int a = *p1; *p2 += 42; int b = *p1; return a == b; // b = a + 42 } int main() { int x = 0; return foo(&x, &x); }
        bstamour 7y ago
  - taylodl 7y ago
    Dammit! Why can I never keep the syntax straight?!

taylodl 7y ago

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.

bstamour 7y ago
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*
- oefrha 7y ago
  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.
  - bstamour 7y ago
    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.
    - rrss 7y ago
      > won't guarantee that some other thread of execution won't change the value under your nose My understanding is that compilers can always assume that there is no other thread involved, which (part of) why C11 atomics are necessary. Is that not the case?
      - H8crilA 7y ago
        Yup, it's a data race (and therefore UB) to access the same memory from two different threads without synchronizing instructions (like mutexes, thread start/join, atomics). It is allowed to concurrently read from const regions. But not concurrently read and write, and definitely not concurrently write.
      - alexlarsson 7y ago
        Yes, but it can't assume any random function call it does doesn't use a different pointer to the same object which is not const. So, even if you don't cast const to non-const pointers you can run into the const value changing.
        bstamour 7y ago
        Concrete example: void foo(const int* const p1, int* const p2) { int a = *p1; *p2 += 42; int b = *p1; return a == b; // b = a + 42 } int main() { int x = 0; return foo(&x, &x); }
      - bstamour 7y ago
- taylodl 7y ago
  Dammit! Why can I never keep the syntax straight?!