From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-03-05 11:59:48
Peter Dimov wrote:
> Andrey Semashev:
>> Peter Dimov wrote:
>> There is no specific reason for that. That feature would just follow
>> from the interface if thread_specific_ptr was consistent with shared_ptr.
> But it's not (semantically) consistent with shared_ptr at all. Making it
> syntactically consistent will just mislead more people. One could even argue
> that it needs to be made even less syntactically consistent with a smart
> pointer than it is now, because it's not like other smart pointers at all.
> Depending on how one looks at it, it represents either a TSD key or an
> auto_ptr with a thread-local storage class.
Agreed. And I for one would personally prefer to see a
thread_specific_value instead of thread_specific_ptr in this case. But
since we have a pointer here, I would like it to behave as a pointer.
And if it has a feature that is similar to other well known pointers, I
would like the feature to have a similar way of use. But that's my HO,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk