On 21/06/14 02:06 AM, Nick Cameron wrote: > bstrie: you're right it is a trade off, but I don't agree that its not > worth it. We're talking about non-atomic incrementing of an integer - > that is pretty much the cheapest thing you can do on a processor (not > free of course, since caching, etc., but still very cheap). I've > programmed a lot in C++ with ref counted pointers and never had a > problem remembering that there is a cost, and it makes using them > pleasant. I found all the clone()s in Rust unpleasant, it really put me > off using ref counting. The transition from using references to using Rc > was particularly awful. Given that this is something C++ programmers > coming to Rust will be used to using, I believe ergonomics is especially > important. > > In this case I don't think we need to aim to be more 'bare metal' than > C++. Transparent, ref counted pointers in C++ are popular and seem to > work pretty well, although obviously not perfectly. > > zwarich: I haven't thought this through to a great extent, and I don't > think here is the right place to plan the API. But, you ought to still > have control over whether an Rc pointer is copied or referenced. If you > have an Rc<T> object and pass it to a function which takes an Rc<T>, it > is copied, if it takes a &Rc<T> or a &T then it references (in the > latter case with an autoderef-ref). If the function is parametric over U > and takes a &U, then we instantiate U with either Rc<T> or T (in either > case it would be passed by ref without an increment, deciding which is > not changed by having a copy constructor). If the function takes a U > literal, then U must be instantiated with Rc<T>. So, you still get to > control whether you reference with an increment or not. > > I think if Rc is copy, then it is always copied. I would not expect it > to ever move. I don't think that is untenable, performance wise, after > all it is what everyone is currently doing in C++. I agree the second > option seems unpredictable and thus less pleasant.
It's a severe performance issue in C++11 with `std::shared_ptr` because it uses atomic reference counting. Even for `Rc<T>`, these writes cause significant issues for alias analysis and end up causing many missed optimizations. Rust needs a way to elide them, and with the `move` keyword gone that means last use analysis or maintaining the current situation where Rust always performs the same operation as C for passing, returning and assignment (a shallow copy). It will be much harder to write failure-safe code if basic operations like assignment can fail.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
