sol_hsa
Reading this thread has been really surprising, I would have expected "const" to help the compiler do better work at collapsing constants.

The C++ FQA (the smug answer to the C++ FAQ) has a great way of explaining this. C++'s unofficial motto should be: "Theoretically, yes. In practice, no." The issue of const helping the compiler is exactly one of those situations. Theoretically, it should help. In practice, it doesn't.

Ultimately, "const" means "semantic constant". It's there (theoretically!) to help the programmer, not the compiler. At the time of writing (and after using C++ for 20 years) I think the only sensible use is as documentation.

sol_hsa
Assuming const DOES help, I think everything should be const by default and only mutable via a keyword.

Yes, the ML solution.

There are some extremely good reasons for this, not the least of which is that it's one way to make the Simula-style object model (which C++ inherited) logically sound.

C++'s unofficial motto should be: "Theoretically, yes. In practice, no."

Sometimes it's "Yes and no." :)

I agree that's const is nice for documentation though. It's swell when you're using someone's library or API and you can see when their function promises not to mutate your data if you pass it.

sol_hsa
Reading this thread has been really surprising, I would have expected "const" to help the compiler do better work at collapsing constants.

Const basically never helps with optimizations. The places where it can help are so rare, I think you'd have to really struggle to find a place you'd care about happening in practice where it actually gave you a speed win.

Mostly the problem is because of both aliasing and "const cast". Const cast was a really, really bad idea - kind of like the rest of the stuff in the C++ spec :) So the optimizer actually should have been able to do a bunch of nice optimization with "const", but because the C++ standard is (as always) poorly thought out, in practice the optimizer can almost never actually use "const" to infer anything at all.

- Casey

Yeah, const_cast sucks for sure. I suspect they threw it in there just because they already had pointer aliasing anyway. It would be interesting to know what was going through their minds though. Speaking of C++ optimizers, const, and aliasing. This video of Chandler Carruth (clang/LLVM dude) is pretty awesome if you're into compiler nerd stuff.

https://www.youtube.com/watch?v=eR34r7HOU14

Quick version: he advocates for passing by-value rather than by-pointer or by-reference. Turns out, passing by-value gives the optimizer the sort of information that you wish using const did.

Important caveat, though: he's specifically talking about inlined functions, not all function calls.

- Casey

ChrisG0x20
I suspect they threw it in there just because they already had pointer aliasing anyway.

The main reason why it's there is because the committee wanted to push people off C-style casts and on to C++-style casts, and C++ still had to work with older C APIs which weren't "const correct".

But it just shows the stupidity involved in the situation. They didn't understand that there are two concepts at play, one of which is always important and the other which is sometimes important, and they chose to support the "sometimes" one :(

More explicitly, the right thing was to have a keyword that means "this value is constant as far as I'm concerned". They never made that keyword. It doesn't exist in the language. What they added instead was a keyword that means, "I myself don't change this value, but someone else might". That's a strictly "programmer notation" concept that literally never matters to the optimizer.

So, big surprise, the C++ designers focused on the one that's strictly about the programmers making themselves happy about some abstract concept, and totally missed the one that would actually have produced better code :(

PAR FOR THE COURSE.

- Casey

Well, as long as you can do memset directly on the data segment, nothing in it is truly constant.. =)

cmuratori
They didn't understand that there are two concepts at play, one of which is always important and the other which is sometimes important, and they chose to support the "sometimes" one :(

To be fair to the designers, "const" is fundamentally about compiler-checked documentation, which is meant to make your programs more correct, not more efficient. That's the theory, and it's not a bad theory for 1983.

To paraphrase the code monk, it was never intended to help the compiler. It was intended to help you if you follow the convention, but a convention is just a convention. All of that "adding const in lots of places" or "dropping const from lots of places" that was mentioned earlier as a royal pain in the whatever (and it is!) is the compiler's way of forcing you to follow the convention.

It would be very, very nice to have read-only values, but I don't think that anyone at the time realised how useful that was. C++ wasn't even designed with threads in mind.

sol_hsa
Well, as long as you can do memset directly on the data segment, nothing in it is truly constant.. =)

That's not really an issue, because this is neither a performance measure nor a security measure.

cmuratori
So, big surprise, the C++ designers focused on the one that's strictly about the programmers making themselves happy about some abstract concept, and totally missed the one that would actually have produced better code :(

If the choice is between more correct code and faster code, the early C++ designers erred in the direction of the former rather than the latter.

Today, we rightly see it as a false dichotomy, but in 1983, with the "software crisis" still recent memory, that wasn't as clear as it is now.

TL;DR: I blame C++, but I don't blame the early C++ designers.

Nice to hear his rants. :lol:

"I’ve never seen a construction worker f**** wave a dead chicken over his hammer before he nails s*** in, right? "