5 ms·

Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only". Something that's const to you might not be const

Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only". Something that's const to you might not be const to something else, so you can never depend on it staying the same. I may be wrong, but my understanding is that Rust's constants are actually constant, and proved as such by the compiler, which is a major difference over C++.

lifthrasiir 13y ago
Rust's "immutable" references ensure that it cannot be changed from either the reference holder or other safe code that has a reference to the same memory region. Note that (as the periodic table suggests) "mutable" references can be downgraded to the immutable references, but the mutable references are locked while the immutable references are active. Once the immutable references are gone (this is checked by the compiler, see the lifetime guide for details) the mutable references can be used again.
pcwalton 13y ago
That's right. If you have an `&` reference to something, the language enforces that it will never be mutated as long as that reference is alive. (Also, if you have an `&mut` reference to something, the language enforces that you're the only one who can mutate it while that reference is alive; that's how iterator invalidation is prevented.)
- haberman 13y ago
  I've often wished for this in C and C++, particularly from an optimization perspective. I always hated that the optimizer cannot assume that the the contents of a struct to which I have a const pointer won't change out from under me when I call another function. It means that it cannot cache members of this struct in callee-save registers; it has to reload them every time. I don't know how much of a speed difference it would actually make in practice, but it bothers me that I cannot express this in C++.
renox 13y ago
> Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only". Yes and that's a huge trap, which is why I'm so annoyed that D has copied 'const' from C++ instead of renaming it to 'view' or 'read'..
scott_s 13y ago
Not only is it "read only," it's not even necessarily read only: #include <iostream> void f(const int* var) { *var = 42; } int main() { int* ptr = new int(78); f(ptr); std::cout << *ptr << std::endl; return 0; } Compiling produces: [scott_s@local Code] g++ const.cpp const.cpp: In function ‘void f(const int*)’: const.cpp:5: error: assignment of read-only location But if we make it: #include <iostream> void f(const int* var) { int* sneaky = const_cast<int*>(var); *sneaky = 42; } int main() { int* ptr = new int(78); f(ptr); std::cout << *ptr << std::endl; return 0; } We get: [scott_s@local Code] g++ const.cpp [scott_s@local Code] ./a.out 42 C++ gives us escape hatches all over the place. I think that the modern approach of compartmentalizing all escape hatches into explicitly regions of "unsafe" code, and providing no escape hatches outside of such regions, is much better.
- deleted 13y ago
  [deleted]

lifthrasiir 13y ago

Rust's "immutable" references ensure that it cannot be changed from either the reference holder or other safe code that has a reference to the same memory region. Note that (as the periodic table suggests) "mutable" references can be downgraded to the immutable references, but the mutable references are locked while the immutable references are active. Once the immutable references are gone (this is checked by the compiler, see the lifetime guide for details) the mutable references can be used again.

pcwalton 13y ago

That's right. If you have an `&` reference to something, the language enforces that it will never be mutated as long as that reference is alive. (Also, if you have an `&mut` reference to something, the language enforces that you're the only one who can mutate it while that reference is alive; that's how iterator invalidation is prevented.)

haberman 13y ago
I've often wished for this in C and C++, particularly from an optimization perspective. I always hated that the optimizer cannot assume that the the contents of a struct to which I have a const pointer won't change out from under me when I call another function. It means that it cannot cache members of this struct in callee-save registers; it has to reload them every time. I don't know how much of a speed difference it would actually make in practice, but it bothers me that I cannot express this in C++.

renox 13y ago

> Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only". Yes and that's a huge trap, which is why I'm so annoyed that D has copied 'const' from C++ instead of renaming it to 'view' or 'read'..

scott_s 13y ago

Not only is it "read only," it's not even necessarily read only: #include <iostream> void f(const int* var) { *var = 42; } int main() { int* ptr = new int(78); f(ptr); std::cout << *ptr << std::endl; return 0; } Compiling produces: [scott_s@local Code] g++ const.cpp const.cpp: In function ‘void f(const int*)’: const.cpp:5: error: assignment of read-only location But if we make it: #include <iostream> void f(const int* var) { int* sneaky = const_cast<int*>(var); *sneaky = 42; } int main() { int* ptr = new int(78); f(ptr); std::cout << *ptr << std::endl; return 0; } We get: [scott_s@local Code] g++ const.cpp [scott_s@local Code] ./a.out 42 C++ gives us escape hatches all over the place. I think that the modern approach of compartmentalizing all escape hatches into explicitly regions of "unsafe" code, and providing no escape hatches outside of such regions, is much better.

deleted 13y ago
[deleted]