Re: [Boost-users] shared_ptr, pimpl, reference semantics, and const correctness

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-10 21:13:53

Braddock Gaskill wrote:

>> This of course doesn't address your const-correctness question, which
>> disappears if you make f.set const. :-)
>
> Yes, I am considering that, but it seems semantically crooked.
>
> What would you recommend?  I'm trying to stay on the same page as your
> N2185 futures proposal.  Your proposal does not define set_value() as
> const, so users will presumably face the same issues.

Very good question. I personally pass shared_ptrs by value all the time 
without feeling any guilt so passing a future by value in the cases where I 
want to call non-const methods is good enough for me.

On the other hand, is this an issue in a split future/promise model? Are you 
moving back to N2185-style "combined" future and if so, why?

There's a discussion on the committee -lib reflector at the moment which has 
raised an interesting point: if no futures remain, it might be desirable (in 
some cases) to cancel the thread that is executing the task as nobody is 
listening for the result. This is the opposite of watching for the case 
where no promise is left and breaking the future::waits, and another 
possible argument in favor of a split future/promise model.

The chances of N2185 being accepted in the standard at this point are 
approximately zero, so there's no need to stick to it except as a sanity 
check against design regressions. :-)