Re: [boost] Upcoming changes to shared_ptr

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-18 10:28:28

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "David Abrahams" <dave_at_[hidden]>
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>> > * shared_*_cast will be renamed to sp_*_cast.
>>
>> Why? Without rationale, this seems like a gratuitous change,
>> especailly since "sp" doesn't mean much to me.
>
> The idea is to use sp_*_cast as a consistent generic syntax for smart
> pointer casts. The shared_*_cast names are too coupled to shared_ptr.
>
>> > * use_count_is_zero will be renamed to bad_weak_ptr.
>>
>> Why? Is a weak_ptr that doesn't refer to anything "bad"?
>
> In the particular context, yes. :-)
>
>> In the standard, at least, "bad_cast" refers to an operation, rather
>> than an object.
>
> I considered a range of names, starting from your earlier
> dangling_weak_reference suggestion. I replaced 'dangling' with 'bad' since
> standard exceptions tend to use the bad_ prefix; I see that Doug has adopted
> the same convention with bad_function_call. 

But in that case, the call itself really is "bad" in some sense.

> The transition from bad_weak_reference to bad_weak_ptr seemed rather
> obvious.
>
> The other option was to put 'expired' somewhere in the name since there is
> weak_ptr::expired(). I considered 'weak_ptr_has_expired' and
> 'reference_has_expired' but bad_weak_ptr looks better to me.

FWIW, I like expired_weak_ptr slightly better than bad_weak_ptr. Maybe
that's just me.

> Naming decisions are hard, aren't they.

Yup.

> Another change that I'm considering is to drop weak_ptr::get(), and
> by implication, operator== and operator<. None of my projects use
> them although no doubt the Real World(tm) will object.

I don't know how many people are using these features; you'd be a
better judge than I would.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution