Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
Message: 2 Date: Mon, 20 Apr 2015 15:40:37 +0100 From: Sam Kellett<samkellett@gmail.com>
To:boost@lists.boost.org Subject: Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing? Message-ID: <CAHK+-Fsy1-sCuMuz+hpjNC2ogAbxUazNY0Qt3xL__bndzkwduw@mail.gmail.com> Content-Type: text/plain; charset=UTF-8
I had a similar idea for a new smart pointer that would aim to obsolete the shared_ptr-to-const idiom. The problem I found with that idiom is that it 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 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).
On 20 April 2015 at 18:07, Thomas Jordan <tomjordan766@gmail.com> wrote:
I had a similar idea for a new smart pointer that would aim to obsolete the
shared_ptr-to-const idiom. The problem I found with that idiom is that it 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 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. The thing I like about the schrodinger_ptr is that I can carry on mutating it while nobody else is looking, it seems with yours you would have to add all data to it on it's construction, is that right? So say it's collecting information from over a network, building up a schrodinger_ptr<std::vector<int>> with a push_back every time it receives something from the network. Once the network sends the finished signal, the object that owns the schrodinger_ptr can spin up a bunch of threads (or whatever) to do some work on the data collected, each of them taking a shallow copy of the pointer. Now each thread has the guarantee that nobody will change that data because they know that as they own it it won't be unique to anybody else.
On April 21, 2015 5:33:26 AM EDT, Sam Kellett <samkellett@gmail.com> wrote:
On 20 April 2015 at 18:07, Thomas Jordan <tomjordan766@gmail.com> 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)
participants (3)
-
Rob Stewart -
Sam Kellett -
Thomas Jordan