"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> "Peter Dimov" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
