[Smart Ptr] Why is weak_ptr a _ptr?
Hi, Is it just me or is it really the worse naming in whole boost library? It is nothing like any other smart pointer. No initialization / construction from raw pointer. No operator * or -> (the very least one would expect from _ptr class). No get(). And many more which I now forgot. My point is that is is not a pointer at all, not even a bit. It only happens to have a member variable returning one and that is hardly a reason to call type pointer-like. It should rather be called shared_tracker or shared_listener or something in that taste ;) Regards, Szymon
On Wed, Oct 13, 2010 at 5:42 AM, Szymon Gatner <szymon.gatner@gmail.com> wrote:
Hi,
Is it just me or is it really the worse naming in whole boost library?
It is nothing like any other smart pointer.
No initialization / construction from raw pointer.
No operator * or -> (the very least one would expect from _ptr class).
No get().
And many more which I now forgot. My point is that is is not a pointer at all, not even a bit. It only happens to have a member variable returning one and that is hardly a reason to call type pointer-like.
It should rather be called shared_tracker or shared_listener or something in that taste ;)
It's not just you. But it's that way for hysterical reasons. The first versions did have operator* and operator->, IIRC. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Szymon Gatner wrote:
Is it just me or is it really the worse naming in whole boost library?
It is nothing like any other smart pointer.
No initialization / construction from raw pointer.
No operator * or -> (the very least one would expect from _ptr class).
No get().
The weak pointer concept originates from garbage-collected languages that have pointers, such as some proposed extensions to C/C++. In such a language, a weak_ptr can be constructed from a raw pointer, can have *, ->, does have get() -- because the raw pointers are "strong", that is, they keep an object from being destroyed because the garbage collector tracks all pointers. (See for example section 5.4 in http://www.usenix.org/publications/library/proceedings/c++94/full_papers/ell... ) In our "ordinary" C++, the equivalent of such a garbage-collected raw pointer is shared_ptr, which is why weak_ptr can only give you a shared_ptr and not a raw pointer.
Is it really the worst? At least it is consistent with the concept of weak references in other languages (Python, C#) And every item in the smart_ptr library ends in either _ptr or _array. Is that so bad? Alex
On 10/13/2010 04:42 AM, Szymon Gatner wrote:
Hi,
Is it just me or is it really the worse naming in whole boost library?
I like good naming as much (really more more than) the average programmer, but sometimes there isn't a great choice. In a case like this, you're lucky when there's common usage to fall back on. Finding amusement in the paradoxes that inevitably arise is a good way to think about and understand them.
It is nothing like any other smart pointer.
No initialization / construction from raw pointer.
No operator * or -> (the very least one would expect from _ptr class).
No get().
And many more which I now forgot. My point is that is is not a pointer at all, not even a bit.
OK, it's not a pointer. Yet it ends in "_ptr"! Now, wouldn't it be just great if this were the worst, most counter-intuitive, inconsistency in the standard language? However, generations of programmers have grown up with the concepts of "strong" and "weak" references. In C and C++ these concepts are have been intimately related to pointers (for obvious reasons). But it turns out not to be possible in C++ to implement weak references that look like pointers directly in a way that avoids the possibility of seriously undefined behavior. I don't see anything inherent in the concept of a weak reference that says it has to look syntactically similar to a strong reference. In fact, it has a more complex interface by definition.
It only happens to have a member variable returning one and that is hardly a reason to call type pointer-like.
No, its interface definition doesn't include any member variables. One could cook up an implementation which didn't have any either. I just think of it (loosely) as an object that has a chance (determined at runtime) of being convertible to a shared_ptr. A lot like boost::optional really.
It should rather be called shared_tracker or shared_listener or something in that taste ;)
Everybody who's ever used a garbage collected system should know what "weak" refers to in this context. I don't know what a "tracker" is supposed to be, and this thing doesn't sound much like a "listener" either. Play the name game to its logical conclusion and eventually it won't make a bit of sense to anyone. :-) - Marsh
I just think of it (loosely) as an object that has a chance (determined at runtime) of being convertible to a shared_ptr. A lot like boost::optional really.
It should rather be called shared_tracker or shared_listener or something in that taste ;)
Everybody who's ever used a garbage collected system should know what "weak" refers to in this context. I don't know what a "tracker" is supposed to be, and this thing doesn't sound much like a "listener" either.
Play the name game to its logical conclusion and eventually it won't make a bit of sense to anyone. :-)
I do agree that names I proposed are bad ;) In fact they suggest that I am against "weak"part of weak_ptr's name which is nothing I had in mind. I do get the purpose they serve and the reason they exist. I do understand the concept of weak references also. My only objection is strictly about "_ptr" part of the name which suggests it is a pointer-like type which is just not true. I see them as extension or even part of shared_ptr implementation. A token or a proxy if you will. Current standard has only one "_ptr". Next one is going to have bunch more. All of them having common (quite expected) interface. What will you answer to a C++ newbie when asked "what a C++ smart pointer is?". Is it really any type that "has a chance of being convertible to a [whatever]_ptr"? Szymon
participants (3)
-
Alex MDC -
Dave Abrahams -
Igor R -
Marsh Ray -
Peter Dimov -
Szymon Gatner