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

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>

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_type+_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
> 

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