Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-07-15 16:05:25

-----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".

In that case, if I was going to add just one policy template parameter, why 
would it be policy support for is_null?  Why not any of the policies 
supported by Loki::SmartPtr?  Most of them have to be more useful than 
is_null, since we haven't even come up with a use case for wanting an is_null 
policy.

> shared_ptr, for 
> example, allows you to specify an arbitrary delete function in the
> constructor.

> This is somewhat analagous to the is_null() function. 

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.

> equally, just in different ways.  In generic_shared in sandbox, half
> of the object's customizability is available per-instance and half is
> available per-type.  I find it a little counterintuitive that the
> customizability semantics are totally different for two equally
> fundamental pointer operations. 

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpeNoUACgkQ5vihyNWuA4UPYwCghDSJvayRAUBTjFNWdh1AgS6b
/AQAoJ7CysijDtJ1N1pG+B/woPZA1cfc
=jFPM
-----END PGP SIGNATURE-----