6 ms·

I could understand why some people like to avoid exceptions. But constness? Really?

coliveira 12y ago
Constness when used on classes introduces a way to create objects that behave differently in different contexts. Are you calling a member function from a const or from a non-const pointer? Depending on that you could be running different code. In my opinion you should make your mind about what the class does: is it mutable? then don't use it with const. Unfortunately, you are still required to use const in many places: copy constructors and operators, for example. However, you can still choose to minimize the use of const, and avoid it whenever possible.
- Negitivefrags 12y ago
  That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
  - smikims 12y ago
    I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include <iostream> void foo(const int& a, int& b) { std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; ++b; std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; } int main() { int a = 1; foo(a, a); } Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes, const is useful, but if you don't know what it actually does it will bite you in the ass, just like most of C++.
    - spoiler 12y ago
      Isn't this inferable from the code itself, though? I was expecting some subtle gotcha, so I had to read your comment three times to realise there was none! It's to be expect that we can change a-through-&b, but not a-through-&a in foo.
      - nostrademons 12y ago
        I think the objection is that b may get passed throughout the program such that it's no longer local to a. Then you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object (probably through a member variable), and suddenly you have some very hard to track down bugs. If you're multi-threaded, you have a data race. You either need to be very strict about creating non-const references to objects, or you need to enforce immutability at the class level. Unfortunately the latter has all sorts of other practical problems, often including efficiency trade-offs or awkward APIs.
        coliveira 12y ago
        > you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object And this is exactly why const means pretty close to nothing. Compilers can't enforce it in so many situations that it is almost like the "auto" keyword in pre-C++11 times.
        nostrademons 12y ago
        It still documents intended behavior, though. C++ is basically a giant clusterfuck if you want the compiler to actually enforce anything - because of pointer arithmetic, there's no guarantee not only that const Foo& a is immutable, but even that it points to a valid Foo or that accessing it won't crash your computer. It's trivially easy to trigger undefined behavior that may do anything up to pwning your computer, whether you make your classes immutable or not. The point of const, access control modifiers, references, static typing, RAII, and all of the other restrictions on C++ programming is to put up giant signposts that say "Don't do that! Here be dragons!" rather than actually prevent you from doing it. If you want the compiler to actually enforce safety properties of the language, use a language like Haskell or Rust.
- nostrademons 12y ago
  Const-ness gives you a way to express a very common pattern in software, where an object is constructed piecemeal in one section of the code and then "frozen" and only const references get passed around from then on. If you were to express this at the class level, you'd need awkward circumlocutions like the Builder pattern, comments on methods, or friend member functions.
  - pkolaczk 12y ago
    The builder pattern is the right way to go. It is stronger than const-references, because once the object is created, there is no way to unfreeze it. It guarantees that the object is truly const, no matter what. On the other hand, const keyword in C++ does not guarantee the object is really const. Your reference may be const, but something else might still have a non-const reference and mutate the object.
    - netheril96 12y ago
      Most of the time `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. In addition, to enforce immutability in C++, you have to disable copy/move constructors and assignment operators, which removes much benefit of using values instead of references.
      - seabee 12y ago
        I see this sometimes in code at work. As soon as you need to stuff one of the 'const' objects into any kind of container you start requiring unique_ptrs everywhere, and then you start thinking how much easier your life would be if you wrote Haskell for a living instead.
      - coliveira 12y ago
        > `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.

Constness when used on classes introduces a way to create objects that behave differently in different contexts. Are you calling a member function from a const or from a non-const pointer? Depending on that you could be running different code. In my opinion you should make your mind about what the class does: is it mutable? then don't use it with const. Unfortunately, you are still required to use const in many places: copy constructors and operators, for example. However, you can still choose to minimize the use of const, and avoid it whenever possible.

Negitivefrags 12y ago
That is an argument to avoid const overloading, not constness generally. I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.
- smikims 12y ago
  I agree that const is overall a good thing; however, it is tricky even in what you might think are simple cases. Take this for example: include <iostream> void foo(const int& a, int& b) { std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; ++b; std::cout << "a: " << a << std::endl; std::cout << "b: " << b << std::endl; } int main() { int a = 1; foo(a, a); } Here the value of a changes in the middle of the function even though it's a const reference, because of aliasing. Here const doesn't mean the value won't change--only that you can't change it through that particular reference. Yes, const is useful, but if you don't know what it actually does it will bite you in the ass, just like most of C++.
  - spoiler 12y ago
    Isn't this inferable from the code itself, though? I was expecting some subtle gotcha, so I had to read your comment three times to realise there was none! It's to be expect that we can change a-through-&b, but not a-through-&a in foo.
    - nostrademons 12y ago
      I think the objection is that b may get passed throughout the program such that it's no longer local to a. Then you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object (probably through a member variable), and suddenly you have some very hard to track down bugs. If you're multi-threaded, you have a data race. You either need to be very strict about creating non-const references to objects, or you need to enforce immutability at the class level. Unfortunately the latter has all sorts of other practical problems, often including efficiency trade-offs or awkward APIs.
      - coliveira 12y ago
        > you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object And this is exactly why const means pretty close to nothing. Compilers can't enforce it in so many situations that it is almost like the "auto" keyword in pre-C++11 times.
        nostrademons 12y ago
        It still documents intended behavior, though. C++ is basically a giant clusterfuck if you want the compiler to actually enforce anything - because of pointer arithmetic, there's no guarantee not only that const Foo& a is immutable, but even that it points to a valid Foo or that accessing it won't crash your computer. It's trivially easy to trigger undefined behavior that may do anything up to pwning your computer, whether you make your classes immutable or not. The point of const, access control modifiers, references, static typing, RAII, and all of the other restrictions on C++ programming is to put up giant signposts that say "Don't do that! Here be dragons!" rather than actually prevent you from doing it. If you want the compiler to actually enforce safety properties of the language, use a language like Haskell or Rust.
nostrademons 12y ago
Const-ness gives you a way to express a very common pattern in software, where an object is constructed piecemeal in one section of the code and then "frozen" and only const references get passed around from then on. If you were to express this at the class level, you'd need awkward circumlocutions like the Builder pattern, comments on methods, or friend member functions.
- pkolaczk 12y ago
  The builder pattern is the right way to go. It is stronger than const-references, because once the object is created, there is no way to unfreeze it. It guarantees that the object is truly const, no matter what. On the other hand, const keyword in C++ does not guarantee the object is really const. Your reference may be const, but something else might still have a non-const reference and mutate the object.
  - netheril96 12y ago
    Most of the time `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. In addition, to enforce immutability in C++, you have to disable copy/move constructors and assignment operators, which removes much benefit of using values instead of references.
    - seabee 12y ago
      I see this sometimes in code at work. As soon as you need to stuff one of the 'const' objects into any kind of container you start requiring unique_ptrs everywhere, and then you start thinking how much easier your life would be if you wrote Haskell for a living instead.
    - coliveira 12y ago
      > `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.