Re: [boost] more comments on new weak_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-12 15:04:20

From: "Darin Adler" <darin_at_[hidden]>
> I think this is one of the main places where the difference in our
opinions
> arises. I am not much swayed by what's most natural to implement and more
> swayed by what seems most natural to use. I understand that given the
> relationship between shared_ptr, weak_count, and shared_count, it's hard
to
> make this shared_ptr constructor result in a 0 when the weak pointer is 0.
> But I think this is making the interface subordinate to the
implementation.
>
> On possibility would be to make this shared_ptr constructor be private,
...

I considered that, too. But then I thought, why hide this constructor from
users? It's useful.

> make
> make_strong() be a friend, and eliminate weak_ptr::get(). Of course, this
> might run afoul of some existing compilers or something like that.

I've never succedeed in making templated friend functions work reliably. :-)
Hence the member function. I don't actually object to the free function
approach; we'll retain a member (not necessarily named 'get') as an
implementation detail - as I've done with operator<.

Although boost::make_strong looks a bit generic to me.
boost::bad_weak_to_shared_cast can be improved, too. Suggestions welcome.

I don't mind removing the boolean weak_ptr queries and/or operator->, if
that's proves a popular opinion. They are there mostly because having used
shared_ptr, users will expect to find them in weak_ptr, too. Explaining why
operator* isn't there is easy: it isn't thread safe, but the others are.