6 ms·

2014 AD For comparison, shared_ptr didn't appear in C++ until C++11, which was approved a mere 998 days ago.

by pohl 12y ago

steveklabnik 12y ago
`shared_ptr` is really closer to `Rc<T>` (the old `@`pointers). `&` in Rust is more like `const&` in C++, with some extra immutability.
- pohl 12y ago
  Would auto_ptr/unique_ptr have been a better comparison?
  - steveklabnik 12y ago
    `unique_ptr` is like `Box<T>` (the old `~`).
    - pohl 12y ago
      Well this is all very humbling. I'm a mostly "managed language" weenie at the moment, but I swear I've read the phrase "ownership semantics" in reference to something in this neck of the C++ woods. Rust is shaping up to pass the Alan Perlis test quite handily as a language worth studying.
      - steveklabnik 12y ago
        No worries. :) Yes, see, in C++, you still need to think about ownership, the compiler just can't help you out. One way of thinking about Rust is "C++, but the compiler understands ownership and memory lifetime." https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmer... is a bit outdated, but you may enjoy giving it a glance.
      - DanWaterworth 12y ago
        For the uninitiated (like me 20 seconds ago): A language that doesn't change the way you think about programming is not worth learning. - Alan Perlis
  - TheCoelacanth 12y ago
    `&`/`mut &` in Rust is equivalent to `const &`/`&` in C++, but with the addition that the compiler makes sure that you don't keep it around for longer than is valid.
- pcwalton 12y ago
  Yup. I might add that `shared_ptr` is thread-safe, while `Rc` isn't (and is enforced by the compiler to not migrate between threads). Because of that `Rc` tends to be much faster than C++ `shared_ptr`, since you only opt into the thread safety if you need it.
  - klodolph 12y ago
    Instead of saying that thread safety is opt-in, I would say that thread safety (at least, avoiding data races) is mandatory in Rust and enforced by the type system... but you only pay for sharing if you need it. C++ has a "pay for what you need" mentality, but do to weak aliasing guarantees, you have to pay for atomic ops on `shared_ptr` whether you need them or not. Just like you have to pay for using `string` because two strings can't safely share data without runtime checks: either you pay for COW (which is less common these days) or you pay for copying. In Rust, the safety of string aliasing is enforced by lifetime analysis.
    - acqq 12y ago
      > In Rust, the safety of string aliasing is enforced by lifetime analysis. Still I have seen a lot of examples where the static strings already present in the data sections have to be explicitly created on the heap just to be used somewhere else. Something like (I write in pseudo, I never programmed in Rust) return (put on heap)"some static string" and it will be probably copied from the data section to the heap just for the content to be read (from the copy on the heap instead of the executable data section) and then the copy on the heap discarded. That's how I understood it at least, please correct me if I'm wrong. Why not having some COW mechanism for such cases built-in in the language, avoiding unnecessary allocations, copying and deallocations?
      - pcwalton 12y ago
        In C++ this is a pretty common thing due to the fact that `const char *` is pretty annoying to work with, so people often use heap-allocated `std::string` instead. In Rust `&'static str` and `StrBuf` are on more equal footing, so it's not necessary to place objects on the heap to make it easier to work with them. Still, some people do it accidentally, so we've recently made some changes to make it harder to shoot yourself in the foot in terms of performance, most notably removing the `~"foo"` syntax for heap allocated string literals (which also had the side effect of making the language easier to read).
asb 12y ago
But has been in Boost for something like 15 years and a version was in TR1. In fact, the motivation for shared_ptr is worth reading: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n145...
- scott_s 12y ago
  It's worth noting, however, that unique_ptr was introduced in C++11 because it relies on move semantics, which were not introduced until then. auto_ptr is not quite the same. See http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 http://www.drdobbs.com/cpp/c11-uniqueptr/240002708
ExpiredLink 12y ago
Stroustup publicly argued against shared_ptr. shared_ptr is as bad as auto_ptr.
- scott_s 12y ago
  What were his arguments? Can you point to something? I spent about 5 minutes googling, but I could only come up with his explanations for when to use it, and when not to use it. For example: http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr

2014 AD For comparison, shared_ptr didn't appear in C++ until C++11, which was approved a mere 998 days ago.

by pohl 12y ago

2014 AD For comparison, shared_ptr didn't appear in C++ until C++11, which was approved a mere 998 days ago.

`shared_ptr` is really closer to `Rc<T>` (the old `@`pointers). `&` in Rust is more like `const&` in C++, with some extra immutability.

pohl 12y ago
Would auto_ptr/unique_ptr have been a better comparison?
- steveklabnik 12y ago
  `unique_ptr` is like `Box<T>` (the old `~`).
  - pohl 12y ago
    Well this is all very humbling. I'm a mostly "managed language" weenie at the moment, but I swear I've read the phrase "ownership semantics" in reference to something in this neck of the C++ woods. Rust is shaping up to pass the Alan Perlis test quite handily as a language worth studying.
    - steveklabnik 12y ago
      No worries. :) Yes, see, in C++, you still need to think about ownership, the compiler just can't help you out. One way of thinking about Rust is "C++, but the compiler understands ownership and memory lifetime." https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmer... is a bit outdated, but you may enjoy giving it a glance.
    - DanWaterworth 12y ago
      For the uninitiated (like me 20 seconds ago): A language that doesn't change the way you think about programming is not worth learning. - Alan Perlis
- TheCoelacanth 12y ago
  `&`/`mut &` in Rust is equivalent to `const &`/`&` in C++, but with the addition that the compiler makes sure that you don't keep it around for longer than is valid.
pcwalton 12y ago
Yup. I might add that `shared_ptr` is thread-safe, while `Rc` isn't (and is enforced by the compiler to not migrate between threads). Because of that `Rc` tends to be much faster than C++ `shared_ptr`, since you only opt into the thread safety if you need it.
- klodolph 12y ago
  Instead of saying that thread safety is opt-in, I would say that thread safety (at least, avoiding data races) is mandatory in Rust and enforced by the type system... but you only pay for sharing if you need it. C++ has a "pay for what you need" mentality, but do to weak aliasing guarantees, you have to pay for atomic ops on `shared_ptr` whether you need them or not. Just like you have to pay for using `string` because two strings can't safely share data without runtime checks: either you pay for COW (which is less common these days) or you pay for copying. In Rust, the safety of string aliasing is enforced by lifetime analysis.
  - acqq 12y ago
    > In Rust, the safety of string aliasing is enforced by lifetime analysis. Still I have seen a lot of examples where the static strings already present in the data sections have to be explicitly created on the heap just to be used somewhere else. Something like (I write in pseudo, I never programmed in Rust) return (put on heap)"some static string" and it will be probably copied from the data section to the heap just for the content to be read (from the copy on the heap instead of the executable data section) and then the copy on the heap discarded. That's how I understood it at least, please correct me if I'm wrong. Why not having some COW mechanism for such cases built-in in the language, avoiding unnecessary allocations, copying and deallocations?
    - pcwalton 12y ago
      In C++ this is a pretty common thing due to the fact that `const char *` is pretty annoying to work with, so people often use heap-allocated `std::string` instead. In Rust `&'static str` and `StrBuf` are on more equal footing, so it's not necessary to place objects on the heap to make it easier to work with them. Still, some people do it accidentally, so we've recently made some changes to make it harder to shoot yourself in the foot in terms of performance, most notably removing the `~"foo"` syntax for heap allocated string literals (which also had the side effect of making the language easier to read).

asb 12y ago

But has been in Boost for something like 15 years and a version was in TR1. In fact, the motivation for shared_ptr is worth reading: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n145...

scott_s 12y ago
It's worth noting, however, that unique_ptr was introduced in C++11 because it relies on move semantics, which were not introduced until then. auto_ptr is not quite the same. See http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 http://www.drdobbs.com/cpp/c11-uniqueptr/240002708

ExpiredLink 12y ago

Stroustup publicly argued against shared_ptr. shared_ptr is as bad as auto_ptr.

scott_s 12y ago
What were his arguments? Can you point to something? I spent about 5 minutes googling, but I could only come up with his explanations for when to use it, and when not to use it. For example: http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr