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

public:

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

//...

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