Timeline for Is it possible to achieve Rust's ownership model with a generic C++ wrapper?
Current License: CC BY-SA 4.0
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 |