[smart_ptr] shared_ptr template type

[Gottlob Frege]

On Wednesday, July 15, 2009, Stewart, Robert <Robert.Stewart@...> wrote:

> Gottlob Frege wrote:
>>
>> My standard answer has now become:
>>    1. use a traits/policy class
>>    2. have the default traits/policy call a free functinon
>>
>> eg:
>>
>> // default free function
>> // or yours will found by ADL if you supply your own
>> //
>> template<class T>  bool is_null_pointer(T p)
>> {
>>    return (p == 0);
>> };
>>
>> // default policy class, calls whatever it finds by ADL
>> // feel free to supply your own policy class instead
>> //
>> template<class T> struct default_smart_pointer_traits
>>    : public smart_pointer_traits<T>
>> {
>>    static bool is_null(pointer p)
>>    {
>>         return is_null_pointer(p);
>>    }
>> };
>
> That's a very nice approach.  You seem to lump traits and policy classes together, but they are clearly not equivalent.  I think a policy class is superior to a traits class, so your numbered bullets should not contain "traits/".
>

Yes I really mean policy. But the original example had a class called
'traits' being passed as a policy and I wanted to make sure it was
understood which class I was talking about. I should have clarified
more.

> What about function templates?  The above seems to apply to class templates only.  Overloading permits one function template to rely on a default functor type while another can take a functor as an argument.  (The former can call the latter, of course.)  The functor argument can be defaulted, provided the default functor is stateless.

I think we could make something work. Do you want to start with an example?

>
> _____
> Rob Stewart

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 July 2009, Zachary Turner wrote:
> If traits are going
> to be supported at all, I think they should be supported first-class,
> and allow one to just parameterize the class with a traits class to
> begin with.


> template<class T, class Traits=default_smart_pointer_traits<T> > class
> generic_shared
> {
> };


I don't intend to add additional template parameters to generic_shared.  I
like shared_ptr, and plan to stay as close to the shared_ptr design as
possible.  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.

My only goal is to make an incremental deviation that adds support for more
than just plain old pointers as the wrapped pointer type.  Incidental to that
is defining some concepts that will allow conforming smart pointer classes to
use each other as their underlying pointer type.  Other than that, I plan to
ape the shared_ptr interface as closely as possible.  It may be that I just
alienate both camps, with the "simplicity" people ignoring it as too complex
and the "configurability" people wanting more, but that's the road I'm on.

The traits stuff in generic_shared is only intended to communicate the
necessary information about a pointer-like class to generic_shared, not to
provide a customization point for the wrapped type.  Such customization would
belong in the template parameter list of the wrapped class (the T in
generic_shared<T>) anyways, not the class wrapping it.  And if it were really
absolutely necessary, the customization could be inserted as a wrapper class
in between generic_shared and T, like

generic_shared<my_customization_wrapper<T, mypolicy> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpd348ACgkQ5vihyNWuA4V67QCgnkqeKdMNV0lag3u5BfMoYnPt
iyEAoJoE3fBpGkFy8YrU9aJCPMIpK9VJ
=+aij
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Bytheway-2]

Zachary Turner wrote:
> The most recent experience I had is in regards to providing custom
> validators for types in boost::program_options.
<snip>

> Another experience I had which I also made a thread about a week or so
> ago was with regards to intrusive_ptr.
<snip>

OK, I understand a little better now.  In each case you want to be able
to provide different behaviour for different uses of the same type.  I
agree with other posters that perhaps this is a confusion between traits
and policies.  I struggle to imagine the same pseudo-pointer type
requiring two different meanings of what null is, but that may be a lack
of imagination on my part :).

> Regarding enable_if, I didn't actually think of that.  But is there a
> reason that if the generic class in question uses a default traits
> class as I suggested, that a user cannot simply provide a template
> specialization of that same class that uses the class template version
> of enable_if to achieve a similar effect?

You can, but only if the author of the class template provides a spare
template parameter for this purpose defaulted to void.  e.g.

template<typename Pointer, typename Enabler = void>
class pointer_policy {
  // ...
};

and I've never seen any library do that.  Moreover, you *can't* do that
if the template is variadic.

John Bytheway

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Zachary Turner-2]

On Wed, Jul 15, 2009 at 11:31 AM, John
Bytheway<jbytheway+boost@...> wrote:

> Zachary Turner wrote:
>> The most recent experience I had is in regards to providing custom
>> validators for types in boost::program_options.
> <snip>
>
>> Another experience I had which I also made a thread about a week or so
>> ago was with regards to intrusive_ptr.
> <snip>
>
> OK, I understand a little better now.  In each case you want to be able
> to provide different behaviour for different uses of the same type.  I
> agree with other posters that perhaps this is a confusion between traits
> and policies.  I struggle to imagine the same pseudo-pointer type
> requiring two different meanings of what null is, but that may be a lack
> of imagination on my part :).

Yes, that was my bad.  I should have said policy and I said traits.  I
can't think of an immediate use off the top of my head either, but
with my luck it will happen someday.

>> 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".  shared_ptr, for
example, allows you to specify an arbitrary delete function in the
constructor.  This is somewhat analagous to the is_null() function.
Of course passing an is_null() function to the constructor would not
be ideal because it would add even more space overhead to the class,
but shared_ptr definitely does allow per-instance customization of at
least 1 aspect of the object being contained.  So I'm not so sure I
agree that it would be straying that much from the design adding a
simple policy.  Both methods stray from the design of shared_ptr
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.  So this could certainly be considered
a deviation from standard shared_ptr behavior.  But it doesn't seem
like more or less of a deviation than adding a default policy.

I can understand the desire to keep it simple and similar to
shared_ptr.  But I guess we have to define what is considered similar
vs dissimilar.  Adding an additional argument with a default type
allows them to be used with identical syntax.  One could grep their
entire codebase, replace all occurences of shared_ptr with
generic_shared, recompile and the code would behave correctly.  I
think that's pretty similar.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----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-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Wed, Jul 15, 2009 at 4:05 PM, Frank Mori Hess<frank.hess@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 16 July 2009, Gottlob Frege wrote:
> - 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.)

I suggest searching the archives of this mailing list for background first.  
For example, there were many long threads about this in 2002, for example:

http://lists.boost.org/Archives/boost/2001/12/22063.php

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

iEYEARECAAYFAkpfH7YACgkQ5vihyNWuA4V3PgCfVP9FB8/JEcwl+cOWEjFdLLW9
iMwAoIRxqrgZRT0K8eMzAxtR7dAfti2Z
=DFLH
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Thu, Jul 16, 2009 at 8:40 AM, Frank Mori Hess<frank.hess@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 16 July 2009, Gottlob Frege wrote:
>> - 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.)
>
> I suggest searching the archives of this mailing list for background first.
> For example, there were many long threads about this in 2002, for example:
>
> http://lists.boost.org/Archives/boost/2001/12/22063.php
>

That is somewhat my point - the topic keeps coming up, so maybe we
should finally do it.  (Or maybe we need a FAQ saying "don't go
there".)

In 2002 there seemed to be lots of policy design discussion.  It would
be interesting to know if we've learned anything over the years.

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 17 July 2009, Gottlob Frege wrote:
> That is somewhat my point - the topic keeps coming up, so maybe we
> should finally do it.

There was the policy_ptr proposal for boost, which I assume is still in the
sandbox.  I even found it listed on some old web copies of the boost review
queue pages, I'm not sure what ultimately happened.

> (Or maybe we need a FAQ saying "don't go
> there".)

I don't want to tell other people they shouldn't work on it, but my personal
opinion is that designing the ultimate policy based smart pointer that is
everything to everyone is a tar pit (which I'm going to avoid).

> In 2002 there seemed to be lots of policy design discussion.  It would
> be interesting to know if we've learned anything over the years.

Well, in 2001 we got Loki::SmartPtr.  In the next couple years we had a bunch
of design debate in boost over a boostified version.  Now we're in 2009, and
somehow shared_ptr is still king.  What I take from that is that there is a
place for exploring other approaches to generalizing smart pointers, such as
the nested matryoshka doll approach I'm playing with in generic_shared.  And
also that I want people who think I should just add a policy template
parameter or two, and giving them default values will solve everything, to
leave me alone :)

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

iEYEARECAAYFAkpgcyoACgkQ5vihyNWuA4XI8gCfTxh9xUUz/t9DJM6c43rrqUso
LWoAn0yZqFat2msQ188hqWHIQwj/XmsJ
=NwTK
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 July 2009, Frank Mori Hess wrote:

> The code is in the file generic_shared.hpp (a fork of shared_ptr.hpp from
> trunk) which is located in the sandbox directory:
>
> https://svn.boost.org/trac/boost/browser/sandbox/fmhess/boost/smart_ptr
>
> The file can be copied into the main boost tree (I've been testing it with
> trunk).  There is also a shared_ptr.hpp in the same directory, which
> implements shared_ptr on top of generic_shared.  I used that mainly so I
> could do some testing of generic_shared using the shared_ptr tests
> unmodified.  The tests pass, except for those which use
> enabled_shared_from_this or weak_ptr.  Beyond that, I've played around a
> little with a few basic tests that use a user-defined pointer type, and
> also use a list iterator as the pointer type (with a deleter that uses the
> iterator to erase the element from its list).
>
> So, the current status is: no generic_weak (analogous to weak_ptr) yet, and
> no shared_from_this support.  Also, there is an unresolved issue with
> respect to casting for non-plain old pointer types.  generic_shared tries
> to apply boost::static/const/dynamic_pointer_cast to its pointer type, but
> ADL doesn't work for boost::static/const/dynamic_pointer_cast, and
> specialization won't work either.  It seems I'll need to add a ADL hook for
> casts as suggested at the end of this thread:
>
> http://lists.boost.org/Archives/boost/2006/06/106406.php
>
> so user-defined pointer types can be support casting.

A little status update: I've got generic_weak and
enable_generic_shared_from_this done, and now all the smart_ptr library tests
pass (with the exception of one test that uses enable_shared_from_this2)
using wrappers for shared_ptr/weak_ptr/enable_shared_from_this which are
built on top of generic_shared/generic_weak/enable_generic_shared_from_this.  
Pointer casts for non-plain old pointer types works now also.  There's no
documentation or tests though (beyond the smart_ptr tests).

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

iEYEARECAAYFAkpmK30ACgkQ5vihyNWuA4VTLwCgkLACR5WGHKnXQQQ8zd+FIGEp
wN0AnR3eakDRViY+eOuhyFXer/QxbwAL
=M/Hu
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost