www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - A vocabulary for "smart pointers"

reply Matthew Wilson <no-one nowhere.no.com> writes:
I'm working on some heavily STL-ified code, and have had cause to require that
ref_ptr instances be get()'ed via a converter policy, as in:

std::find_if(  stlsoft::transformer(m_tokens.begin(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
           ,   stlsoft::transformer(m_tokens.end(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
           ,   std::bind1st(comstl::com_S_OK(comstl::is_same_object), token));

I've just implemented an invoke_get() function adaptor, as follows:

namespace stlsoft
{

    template <typename T>
    struct get_invoker
    {
    public:
        typename T::element_type operator ()(T &t) const
        {
            return t.get();
        }
    };

    template <typename T>
    inline get_invoker<T> invoke_get()
    {
        return get_invoker<T>();
    }

} // namespace stlsoft

To make this work (without traits), I've added the member type element_type to
ref_ptr, following on the lines of auto_ptr.

Naturally, this got me wondering about whether there exists a standard
vocabulary for (the member types of) "smart pointer" types, or more
specifically, those that are get()-able, i.e. have get() methods (with the
conventional semantics of exposing the managed resource to client code, in a
non-implicit fashion).

Within STLSoft there are get()-able facades and smart pointers for a wide
spectrum of different resource types, including the following
(facade/smart-ptr, with get() return type):

 - comstl::bstr (BSTR)
 - comstl::guid (GUID&)
 - inetstl::connection (HINTERNET)
 - inetstl::session (HINTERNET)
 - stlsoft::auto_destructor (value_type*)
 - stlsoft::ptr_proxy (value_type*)
 - stlsoft::ref_ptr (counted_type*)
 - stlsoft::scoped_handle (resource_type)
 - stlsoft::shared_ptr (const_pointer)
 - unixstl::module (module_handle_type)
 - winstl::module (module_handle_type)
 - winstl::reg_key/reg_key_sequence/reg_value_sequence (hkey_type)

Clearly this list shows that the STLSoft libraries are not consistent in the
name of the member type(s) that are returned by get()-able types.

My feeling is that the others should follow the example of scoped_handle, and
define a member type resource_type, e.g.

 - comstl::bstr::resource_type === BSTR
 - unixstl::module::resource_type === void*
 - winstl::reg_key_sequence::resource_type === HKEY

and so on.


Does anyone have any comment on:
 - what conventions exists for get()-able types' member types in other
libraries, in standards proposals/thinking
 - whether it's even worth trying to establish a convention; you might consider
the effort fruitless and require the use of a traits class (that has an
undefined primary template)
 - whether it's worth proposing a standard member type name, e.g.
resource_type, for the C++ standard for get()-able types (if such a proposal
has not already been done, of course)
 - any other thoughts.

Cheers

Matthew
Apr 02 2007
next sibling parent Matthew Wilson <no-one nowhere.no.com> writes:
Sorry. Typo. :$

Matthew Wilson Wrote:

 I'm working on some heavily STL-ified code, and have had cause to require that
ref_ptr instances be get()'ed via a converter policy, as in:
 
 std::find_if(  stlsoft::transformer(m_tokens.begin(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
            ,   stlsoft::transformer(m_tokens.end(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
            ,   std::bind1st(comstl::com_S_OK(comstl::is_same_object), token));
 
 I've just implemented an invoke_get() function adaptor, as follows:
 
 namespace stlsoft
 {
 
     template <typename T>
     struct get_invoker
     {
     public:
         typename T::element_type operator ()(T &t) const

should read: typename T::element_type* operator ()(T &t) const
         {
             return t.get();
         }
     };
 

<snip>
Apr 02 2007
prev sibling parent reply Adi Shavit <adish gentech.co.il> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

For what it's worth, Boost's shared_ptr defines these typedefs:

    template<class T> class shared_ptr
    {
    //...

    public:

        typedef T element_type;
        typedef T value_type;
        typedef T * pointer;

    //...

Apparently scoped_ptr, static_move_ptr and others 
<http://www.google.com/codesearch?hl=en&lr=&q=typedef+element_ty
e+_ptr&btnG=Search> 
define element_type too.

Loki's SmartPtr <http://loki-lib.sourceforge.net/html/a00674.html> 
defines the following (policy defined) typedefs: StoredType, 
InitPointerType, PointerType, ReferenceType

But, perhaps you should post this question to one of the comp.lang.c++.* 
groups.

Adi


Matthew Wilson wrote:
 I'm working on some heavily STL-ified code, and have had cause to require that
ref_ptr instances be get()'ed via a converter policy, as in:

 std::find_if(  stlsoft::transformer(m_tokens.begin(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
            ,   stlsoft::transformer(m_tokens.end(), m_tokens.end(),
stlsoft::invoke_get<IToken_ptr>())
            ,   std::bind1st(comstl::com_S_OK(comstl::is_same_object), token));

 I've just implemented an invoke_get() function adaptor, as follows:

 namespace stlsoft
 {

     template <typename T>
     struct get_invoker
     {
     public:
         typename T::element_type operator ()(T &t) const
         {
             return t.get();
         }
     };

     template <typename T>
     inline get_invoker<T> invoke_get()
     {
         return get_invoker<T>();
     }

 } // namespace stlsoft

 To make this work (without traits), I've added the member type element_type to
ref_ptr, following on the lines of auto_ptr.

 Naturally, this got me wondering about whether there exists a standard
vocabulary for (the member types of) "smart pointer" types, or more
specifically, those that are get()-able, i.e. have get() methods (with the
conventional semantics of exposing the managed resource to client code, in a
non-implicit fashion).

 Within STLSoft there are get()-able facades and smart pointers for a wide
spectrum of different resource types, including the following
(facade/smart-ptr, with get() return type):

  - comstl::bstr (BSTR)
  - comstl::guid (GUID&)
  - inetstl::connection (HINTERNET)
  - inetstl::session (HINTERNET)
  - stlsoft::auto_destructor (value_type*)
  - stlsoft::ptr_proxy (value_type*)
  - stlsoft::ref_ptr (counted_type*)
  - stlsoft::scoped_handle (resource_type)
  - stlsoft::shared_ptr (const_pointer)
  - unixstl::module (module_handle_type)
  - winstl::module (module_handle_type)
  - winstl::reg_key/reg_key_sequence/reg_value_sequence (hkey_type)

 Clearly this list shows that the STLSoft libraries are not consistent in the
name of the member type(s) that are returned by get()-able types.

 My feeling is that the others should follow the example of scoped_handle, and
define a member type resource_type, e.g.

  - comstl::bstr::resource_type === BSTR
  - unixstl::module::resource_type === void*
  - winstl::reg_key_sequence::resource_type === HKEY

 and so on.


 Does anyone have any comment on:
  - what conventions exists for get()-able types' member types in other
libraries, in standards proposals/thinking
  - whether it's even worth trying to establish a convention; you might
consider the effort fruitless and require the use of a traits class (that has
an undefined primary template)
  - whether it's worth proposing a standard member type name, e.g.
resource_type, for the C++ standard for get()-able types (if such a proposal
has not already been done, of course)
  - any other thoughts.

 Cheers

 Matthew
   

Apr 08 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  "Adi Shavit" <adish gentech.co.il> wrote in message =
news:evbm3f$2v8o$1 digitalmars.com...
  For what it's worth, Boost's shared_ptr defines these typedefs:

template<class T> class shared_ptr
{
//...

public:

    typedef T element_type;
    typedef T value_type;
    typedef T * pointer;

//...Apparently scoped_ptr, static_move_ptr and others define =
element_type too.

  Loki's SmartPtr defines the following (policy defined) typedefs: =
StoredType, InitPointerType, PointerType, ReferenceType

  But, perhaps you should post this question to one of the =
comp.lang.c++.* groups.


I did. Just didn't get much in the way of interest.No matter, I've =
decided on resource_type and const_resource_type (with the latter being =
optional, and inferrable from resource_type).
Apr 11 2007