4 ms·
No. If you used const correctly, you couldn't change anything about the class, therefore it was also thread-safe. If your class had mutable members or got arou
by dbcfd 13y ago
No.
If you used const correctly, you couldn't change anything about the class, therefore it was also thread-safe. If your class had mutable members or got around the const guarantee through backdoors (e.g. pointer passed in that modified another object, or member pointers that called non-const methods), it wasn't correctly const and shouldn't have been marked as such.
There is nothing wrong with the const keyword, just with programmers who marked things const that broke the const contract. There is no language ambiguity on this.
- ambrop7 13y agoThe language doesn't define "correct const usage" the way you see it. It only specifies what is defined and undefined behavior. Casting a pointer-to-const to a pointer-to-non-const and modifying an object via that is defined behavior as long as the original object is not declared const. (see my comment above)
- dbcfd 13y agoAnd that's where functional programming languages are gaining over imperative/oo languages for multi-threaded behavior. Because you have the ability to break the contract, it produces code that is harder to follow, harder to learn for beginners, and harder to debug in parallel/concurrent contexts. It's a shame that this is more best practice. Hopefully the specification will address this in the future that you can only call const from const, and cast from const to non-const can't be used.