Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-07-16 00:07:47

On Wed, Jul 15, 2009 at 4:05 PM, Frank Mori Hess<frank.hess_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 15 July 2009, Zachary Turner wrote:
>> >> If you want to go the route of high configurability and multiple
>> >> template parameters, it would probably be better to start from the
>> >> design of Loki::SmartPtr than boost::shared_ptr.
>>
>> I don't think I was necessarily proposing something "highly
>> configurable".  Just "moderately configurable".
>
>
> Deleters don't effect the type of the shared_ptr.
>
> What action a shared_ptr should take when its reference count reaches zero
> (the deleter) is a property of the shared_ptr.  But whether or not a pointer
> object of type T is null or not is a property of the pointer object, not a
> property of whatever generic_shared<T> it may happen to be wrapped inside
> (except in the sense that the generic_shared<T> exposes the existing
> properties of T).
>
>> but shared_ptr definitely does allow per-instance customization of at
>> least 1 aspect of the object being contained.
>
> As I noted above, deleters are a customization of the reference-counting
> features of shared_ptr, not a method of reinterpreting the properties of the
> pointer the shared_ptr contains.
>
>
> I don't consider is_null_pointer a customization.  It's a query that allows
> generic_shared to discover a property of the pointer it contains.  It's not
> meant to set or create properties.
>
> Also, if you wanted to change the behavior of is_null_pointer per instance,
> you can do so.  is_null_pointer is passed a pointer to the object in question
> and can ask the object whether or not it wants to be considered null.  And if
> the pointer class is some 3rd party type, you could wrap it inside your own
> pointer wrapper class if you need to add extra per-object state to decide if
> the object is null or not.
>

A few thoughts, in reply to this post as well as a few others above:

- if you are looking for examples for when you might have different
behaviours for the same *type*, maybe Win32 loosely typed 'handles'
might help. ie:
    generic_shared<HWND, ...>
    generic_shared<HMENU, ...>
etc
Depending on your compile settings (ie #define STRICT) you may have
HWND == HMENU == int (or not).
But you might want their behaviours to be different.  Same might apply
to intrusive_ptr<HMENU>, etc.  (For example, depending on how HMENUs
are created (Dynamic or from RC file) they may or may not be
automatically ref-counted by Windows.  etc.)

- Maybe a more generic smart_ptr IS what we need (ie towards Loki
policy-based SmartPtr).  Particularly since I've seen the same
discussion about intrusive_ptr.  Or maybe not.  It is worth
considering.  One ptr to rule them all?  (There would still be the
specialized smart_ptr and intrusive_ptr of course, for simplicity and
compatibility.)

- The REAL question is what are the properties?  ie the Concepts?
ie I see a post above listing the properties of the internal 'pointer':

1) has operator->() and operator*()
2) either has value_type/reference/pointer member typedefs, or a
specialization of boost::smart_pointer_traits
3) has a is_null_pointer() free function findable by ADL
4) supports (in)equality comparison

Leaving aside the details of free function vs policy, are these all
the requirements of the pointer?  What about

5) deletion.  (currently covered via the optional deleter function in
smart_ptr, but I'm just trying to list everything).

Does this also cover the requirements for intrusive_ptr?  Any other
'smart' pointer?  Obviously for intrusive_ptr we would add the
requirements of

6) has internal refcount - ie supports incr_ref/decr_ref (somehow - ie
currently via ADL)
7) ?

And lastly, what are the Concepts that the smart_ptr itself is implementing?
1) it acts like a pointer (ie 1, 2, .... above)
2) is resetable?
3) convertable to weak pointer?  Or is that external to smart_ptr?

4) once set/initted it won't suddenly become null (I think that's the
main point, right?)

 Is it the same for all smart pointers?

Regardless of whether anyone writes the POE (Pointer Of Everything -
ie Theory Of Everything in Physics), it might be worthwhile to sort
out these conditions so that we know what is currently being written
(if anything).  And then maybe we could even decide which pieces
should be traits/policies/ADL/constructor_params/etc/etc/etc

At least I'd find it interesting.
Tony