5 ms·

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_ba

by jpcfl 3y ago

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_bar(Foo const* self); Just looking at this signature, I know that calling `bar()` will not modify the state of the object. This is incredibly valuable information to the reader. Furthermore, if I want to create a `Foo` constant, I can only call this function if it is `const`. static Foo const a_foo = FOO_INIT(&some_params); return Foo_bar(&a_foo); // Will not compile without 'const' in function `const` is valuable to the compiler, since `a_foo` can be placed into ROM on some platforms like MCUs, saving precious RAM.

paulddraper 3y ago
Agreed; const is one of those features that is so good I wish a lot of other languages (e.g. java) had it.
- epcoa 3y ago
  const in C and C++ are an abomination. On a pointer they don’t tell the compiler to do shit, because they can’t. That I can agree with TFA. However I agree with the GP that dismissing it entirely is a little misplaced. It serves as a hint/documentation and I think the article undersells the value of rodata (not the pointer use of const which is basically shit). I mean I have seen at least a few SIGSEGV/aborts due to attempted writes to ro memory. Also like, one of the few modern justifications for C, embedded, const still has important link time meaning.
- skovati 3y ago
  FWIW, Java does have the "final" keyword.
  - flakes 3y ago
    Final only protects the variable from being assigned a new reference (similar to a const pointer). It doesn’t protect any of the underlying data held by the object from being changed, unless the entire hierarchy has every field declared final as well. I still use final heavily in all of my Java code, but it doesnt convey the full intent I would like it to.
    - _old_dude_ 3y ago
      I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const. The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.
      - layer8 3y ago
        It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.
        paulddraper 3y ago
        No, there are two classes -- mutable and immutable -- that both implement the immutable interface.
        layer8 3y ago
        Yes, so three classes. I’m counting a Java interface as a class, because it is the same as a purely abstract class. In any case, three different named types. As a side note, I would say the interface is unmodifiable, not immutable, because references of the interface type may refer to mutable instances that can mutate while you use it through the interface. Immutable = doesn’t change state, unmodifiable = you can’t change it’s state via that reference (but it might change it’s state due to other concurrent code holding a mutable reference). This nomenclature comes from the “unmodifiable” collection wrappers in Java, which don’t make the underlying object immutable.
      - taylorius 3y ago
        Java has many great qualities, but concision is not one of them.
david2ndaccount 3y ago
You only know there are no mutations if Foo itself does not contain any indirections. Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const as long as it is not originally a variable declared as const (so in your static Foo example it would be UB to cast away const). static + const is valuable, but const parameters are merely a convention, there is no actual enforcement around them and due to aliasing the compiler generally can’t assume the parameter doesn’t actually change anyway.
- lelanthran 3y ago
  > Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const No, but it can warn you! The type is meant to capture programmer intention, and if you use `const` the compiler can warn you that your intention does not match the intention of the existing code (like, the intention of the author who wrote Foo_Bar).
- jpcfl 3y ago
  True. I should rephrase to say `const` strongly suggests that a function does not change the observable state of a variable.
glitchc 3y ago
I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.
- kibibu 3y ago
  Should perhaps be int Foo_bar(const Foo * self);
  - glitchc 3y ago
    Even then, some other function can change the memory at the address of self while this one is executing, especially in concurrent systems. Additionally, any other pointer pointing to the same address can also modify self's memory. const in this case is really just "scout's honour".
  - jenadine 3y ago
    `const Foo*` and `Foo const*` are exactly the same and just a question of style (east-const vs. west-const) Not to be confused with `Foo *const`
    - PennRobotics 3y ago
      For anyone thinking, "wtf const pointer order??" fall back on the spiral rule: https://c-faq.com/decl/spiral.anderson.html https://c-faq.com/decl/spiral.anderson.html
- jpcfl 3y ago
  > const does not guarantee that the memory at the location pointed to won't change I didn't say this. I said a `const` function tells the reader that the state of an object doesn't change. Another reader correctly pointed out that there are ways to modify the state of a `const` parameters (indirection and const cast), but I would argue that such an API is poorly-designed. To qualify my original comment, a reader only knows a function doesn't change an object's state if the API is well-designed.
__MatrixMan__ 3y ago
Sorry for going off topic, but something fun I've learned lately is that in Nim (which compiles to C) changing: let x = foo() ... to ... const x = foo() ...runs foo at compile time to get the value. I dunno I just thought it was neat.

by jpcfl 3y ago

paulddraper 3y ago

Agreed; const is one of those features that is so good I wish a lot of other languages (e.g. java) had it.

epcoa 3y ago
const in C and C++ are an abomination. On a pointer they don’t tell the compiler to do shit, because they can’t. That I can agree with TFA. However I agree with the GP that dismissing it entirely is a little misplaced. It serves as a hint/documentation and I think the article undersells the value of rodata (not the pointer use of const which is basically shit). I mean I have seen at least a few SIGSEGV/aborts due to attempted writes to ro memory. Also like, one of the few modern justifications for C, embedded, const still has important link time meaning.
skovati 3y ago
FWIW, Java does have the "final" keyword.
- flakes 3y ago
  Final only protects the variable from being assigned a new reference (similar to a const pointer). It doesn’t protect any of the underlying data held by the object from being changed, unless the entire hierarchy has every field declared final as well. I still use final heavily in all of my Java code, but it doesnt convey the full intent I would like it to.
  - _old_dude_ 3y ago
    I remember James Gosling saying, a long time ago, that the whole class should be either mutable or not so you do not need to tag some methods with const. The consequence is that you may define two classes, one non-mutable and one mutable like String/StringBuilder.
    - layer8 3y ago
      It means you have to triplicate each mutable class, because besides the immutable variant you also need the common interface (e.g. CharSequence), in order to pass mutable instances to read-only functions.
      - paulddraper 3y ago
        No, there are two classes -- mutable and immutable -- that both implement the immutable interface.
        layer8 3y ago
        Yes, so three classes. I’m counting a Java interface as a class, because it is the same as a purely abstract class. In any case, three different named types. As a side note, I would say the interface is unmodifiable, not immutable, because references of the interface type may refer to mutable instances that can mutate while you use it through the interface. Immutable = doesn’t change state, unmodifiable = you can’t change it’s state via that reference (but it might change it’s state due to other concurrent code holding a mutable reference). This nomenclature comes from the “unmodifiable” collection wrappers in Java, which don’t make the underlying object immutable.
    - taylorius 3y ago
      Java has many great qualities, but concision is not one of them.

david2ndaccount 3y ago

You only know there are no mutations if Foo itself does not contain any indirections. Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const as long as it is not originally a variable declared as const (so in your static Foo example it would be UB to cast away const). static + const is valuable, but const parameters are merely a convention, there is no actual enforcement around them and due to aliasing the compiler generally can’t assume the parameter doesn’t actually change anyway.

lelanthran 3y ago
> Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const No, but it can warn you! The type is meant to capture programmer intention, and if you use `const` the compiler can warn you that your intention does not match the intention of the existing code (like, the intention of the author who wrote Foo_Bar).
jpcfl 3y ago
True. I should rephrase to say `const` strongly suggests that a function does not change the observable state of a variable.

glitchc 3y ago

I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.

kibibu 3y ago
Should perhaps be int Foo_bar(const Foo * self);
- glitchc 3y ago
  Even then, some other function can change the memory at the address of self while this one is executing, especially in concurrent systems. Additionally, any other pointer pointing to the same address can also modify self's memory. const in this case is really just "scout's honour".
- jenadine 3y ago
  `const Foo*` and `Foo const*` are exactly the same and just a question of style (east-const vs. west-const) Not to be confused with `Foo *const`
  - PennRobotics 3y ago
    For anyone thinking, "wtf const pointer order??" fall back on the spiral rule: https://c-faq.com/decl/spiral.anderson.html https://c-faq.com/decl/spiral.anderson.html
jpcfl 3y ago
> const does not guarantee that the memory at the location pointed to won't change I didn't say this. I said a `const` function tells the reader that the state of an object doesn't change. Another reader correctly pointed out that there are ways to modify the state of a `const` parameters (indirection and const cast), but I would argue that such an API is poorly-designed. To qualify my original comment, a reader only knows a function doesn't change an object's state if the API is well-designed.

__MatrixMan__ 3y ago

Sorry for going off topic, but something fun I've learned lately is that in Nim (which compiles to C) changing: let x = foo() ... to ... const x = foo() ...runs foo at compile time to get the value. I dunno I just thought it was neat.