c++.stlsoft - A vocabulary for "smart pointers"
- Matthew Wilson (50/50) Apr 02 2007 I'm working on some heavily STL-ified code, and have had cause to requir...
- Matthew Wilson (5/26) Apr 02 2007 should read:
- Adi Shavit (19/70) Apr 08 2007 For what it's worth, Boost's shared_ptr defines these typedefs:
- Matthew Wilson (21/21) Apr 11 2007 charset="iso-8859-1"
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
Matthew Wilson <no-one nowhere.no.com> 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) constshould read: typename T::element_type* operator ()(T &t) const{ return t.get(); } };<snip>
Apr 02 2007
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
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