Skip to main content
16 events
when toggle format what by license comment
S Mar 9, 2021 at 11:16 history suggested jaggi CC BY-SA 4.0
convert title to a proper question
Mar 9, 2021 at 6:43 review Suggested edits
S Mar 9, 2021 at 11:16
Dec 24, 2018 at 20:16 vote accept Brannon
Nov 17, 2017 at 20:19 comment added 8bittree @JerryJeremiah Rust has a wide variety of reference types. The basic ones, &, do not require any sort of promoting to be used. If you try to get a &mut while you've still got another reference (mutable or not) to the same item, you won't be able to compile. RefCell<T> moves the check to run time, so you'll get a panic if you try to .borrow_mut() something that already has an active .borrow() or .borrow_mut(). Rust also has Rc<T> (shared owning pointer) and its sibling Weak<T>, but those are about ownership, not mutability. Stick a RefCell<T> inside them for mutability.
Nov 16, 2017 at 22:39 answer added amon timeline score: 12
Oct 15, 2016 at 20:17 comment added Jerry Jeremiah I don't know Rust but it seems to me that the mutable and readonly references are very similar to owning and weak pointers. Both mutable and readonly can be weak pointers. You only allow one mutable owning pointer at a time and the weak pointers need to be upgraded to owning pointers before they can before used. It has to be done at runtime. But what happens in Rust when you want a mutable reference to something that already has multiple readonly references?
May 14, 2016 at 2:53 comment added Akshat Mahajan Aren't scope ownerships already implemented by smart pointers in C++11?
May 11, 2016 at 18:44 comment added Brannon @delnan, I was specifically interested in the item CodesInChaos summarized: having the compiler ensure that an item is not mutable in multiple threads simultaneously.
May 11, 2016 at 14:37 comment added ppetraki You could use the same concept as a recursive mutex uses which is "which thread locked me to begin with?". So you would create a "threadsafe guard accessor" of sorts for whatever it is you're passing around that would only allow the thread who "owns" the object to change it. IMHO It's probably more trouble than it's worth.; A cleaner design that facilitates understanding, debug, and fault injection adds more value than "fearless concurrency".
May 11, 2016 at 6:10 comment added user7043 @CodesInChaos I know Rust, and I agree that the things you mention seem impossible to do (at compile time) with C++. But I would like to hear from OP which things they want to do in C++, to give a targeted assessment of whether that is possible.
May 11, 2016 at 1:20 history tweeted twitter.com/StackProgrammer/status/730205894647152641
May 10, 2016 at 20:38 comment added CodesInChaos You don't think you can express borrowing in a way that the C++ compiler could verify, so you'd have to resort to runtime enforcement with the associated performance hit.
May 10, 2016 at 20:37 comment added CodesInChaos @delnan (Safe) Rust guarantees that you never have more than one mutable reference to something at a time and that you never have have a mutable reference to a thing you're also having read-only references to. It also has some restrictions on transferring data between threads. Together these prevent a significant class of threading related bugs and make reasoning about the state of objects easier, even in single threaded code.
May 10, 2016 at 19:58 comment added user7043 What does "transfer ownership to any method to which it may be passed" mean? C++ has move constructors, they're just not the default. Please elaborate.
May 10, 2016 at 17:57 comment added Martin Ba Some quotes from the link would improve this question
May 10, 2016 at 16:30 history asked Brannon CC BY-SA 3.0