4 ms·

Everybody who has tried to use const in even medium-sized C++ codebases is familiar with the behavior discussed here. It's not about specific examples, it is ab

by jblow 11y ago

Everybody who has tried to use const in even medium-sized C++ codebases is familiar with the behavior discussed here. It's not about specific examples, it is about what happens when you have a lot of code.

golergka 11y ago
Can you please provide some examples, so I can better understand what you mean?
- trashcan 11y ago
  If you make a function that accepts an unsigned int, and then you try to pass in a const unsigned int, you will need to either typecast it, make a new function, or change the function to only accept const unsigned ints. Although it's been a long time since I coded in C/C++, correct me if I'm wrong.
  - Joky 11y ago
    That sounds completely wrong, unless the function takes a reference to the unsigned int.
  - StephanTLavavej 11y ago
    You're incorrect, for C89 through C++17. I'd recommend not making statements about languages you've forgotten. In the C++ Working Paper, the Standardese is N4527 5.2.2 [expr.call]/4 "When a function is called, each parameter (8.3.5) shall be initialized (8.5, 12.8, 12.1) with its corresponding argument." followed by 8.5 [dcl.init] where /17.8 has a nice example: "Note: An expression of type "cv1 T" can initialize an object of type "cv2 T" independently of the cv-qualifiers cv1 and cv2. int a; const int b = a; int c = b;" (A "cv-qualifier" is const or volatile; they behave similarly in many contexts, hence the collective terminology for convenience.)
    - trashcan 11y ago
      I stand corrected, thank you.
- agumonkey 11y ago
  I'm no C nor Ada expert, but I think he means in C `const` is a data type modifier, whereas in Ada it's a function modifier, making the concerns orthogonal. I'm never happy when I see warning about `const` being lifted by some function in C. I think that's what parent is referring to.
Negitivefrags 11y ago
I'm someone with a codebase where we practice const correctness and we haven't had a problem with it. We were being const correct from the start so we don't have the problems associated with trying to change that midstream. Assuming you do it from the start you shouldn't be running in to issues.
- mark-r 11y ago
  Exactly right. But the example was of combining two code bases, one of which tried to maintain const correctness and one which had utter disregard for it. If you don't believe in const correctness in the first place, the work of making your code compatible can seem intractable.
fsloth 11y ago
Hmm, I'm not sure if codebase with millions of lines is 'medium' or 'large' but from my experience const is great even there. Of course, modifying existing code to become const correct in interfaces where previously it was not can cascade to a point where a majority of the code needs a rewrite, so I can see situations where adding const to an old interface can cause lots of grief. But from my experience const really helps in enforcing directed graph constraints on logic and data flow which is great - and forces code to be easier to reason about.

by jblow 11y ago

golergka 11y ago

Can you please provide some examples, so I can better understand what you mean?

trashcan 11y ago
If you make a function that accepts an unsigned int, and then you try to pass in a const unsigned int, you will need to either typecast it, make a new function, or change the function to only accept const unsigned ints. Although it's been a long time since I coded in C/C++, correct me if I'm wrong.
- Joky 11y ago
  That sounds completely wrong, unless the function takes a reference to the unsigned int.
- StephanTLavavej 11y ago
  You're incorrect, for C89 through C++17. I'd recommend not making statements about languages you've forgotten. In the C++ Working Paper, the Standardese is N4527 5.2.2 [expr.call]/4 "When a function is called, each parameter (8.3.5) shall be initialized (8.5, 12.8, 12.1) with its corresponding argument." followed by 8.5 [dcl.init] where /17.8 has a nice example: "Note: An expression of type "cv1 T" can initialize an object of type "cv2 T" independently of the cv-qualifiers cv1 and cv2. int a; const int b = a; int c = b;" (A "cv-qualifier" is const or volatile; they behave similarly in many contexts, hence the collective terminology for convenience.)
  - trashcan 11y ago
    I stand corrected, thank you.
agumonkey 11y ago
I'm no C nor Ada expert, but I think he means in C `const` is a data type modifier, whereas in Ada it's a function modifier, making the concerns orthogonal. I'm never happy when I see warning about `const` being lifted by some function in C. I think that's what parent is referring to.

Negitivefrags 11y ago

I'm someone with a codebase where we practice const correctness and we haven't had a problem with it. We were being const correct from the start so we don't have the problems associated with trying to change that midstream. Assuming you do it from the start you shouldn't be running in to issues.

mark-r 11y ago
Exactly right. But the example was of combining two code bases, one of which tried to maintain const correctness and one which had utter disregard for it. If you don't believe in const correctness in the first place, the work of making your code compatible can seem intractable.

fsloth 11y ago

Hmm, I'm not sure if codebase with millions of lines is 'medium' or 'large' but from my experience const is great even there. Of course, modifying existing code to become const correct in interfaces where previously it was not can cascade to a point where a majority of the code needs a rewrite, so I can see situations where adding const to an old interface can cause lots of grief. But from my experience const really helps in enforcing directed graph constraints on logic and data flow which is great - and forces code to be easier to reason about.