On April 21, 2015 5:33:26 AM EDT, Sam Kellett
On 20 April 2015 at 18:07, Thomas Jordan
wrote: shared_ptr-to-const idiom. The problem I found with that idiom is
only guarantees that you can't change it. There's no promise that somebody else doesn't have a non-const ref to the data and so it could in
I had a similar idea for a new smart pointer that would aim to obsolete the that it the worst
case completely change from under your feet (even if you know it won't get destroyed).
ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, implementation detail. Its interface just deals in values (as shown in the example usage).
Absolutely! Hence the ref in the name. :)
I kept the pointer as part of the interface seeing as I saw it as a smart pointer to replace another smart pointer, but either direction is not wrong for sure.
"Value" doesn't suggest pointer semantics. What's more, I think the value (no pun intended) of such a class is to actually provide value semantics, hiding the pointer semantics. ___ Rob (Sent from my portable computation engine)