Re: n2351: Improving shared_ptr for C++0x

[CoffeeBuzz <chris dot fairles at gmail dot com>]

Jonathan Wakely-4 wrote:
> 
> re http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm
> 
> Once GCC has std::unique_ptr, should it re-use std::default_delete as
> shared_ptr's default deleter, instead of _Sp_deleter?  This would be
> observable by users, who could use
> std::get_deleter<std::default_delete> to test for it. Code that relied
> on that implementation detail would not be portable.
> 

I have a unique_ptr implementation ready to be submitted (waiting for papers
to go through FSF as well). The default_deleter's look like this:

  template <class _Tp> 
    struct default_delete : public unary_function<_Tp*,void> {      
      default_delete() {}
      template <class _Up> default_delete(const default_delete<_Up>&) {}
      void operator()(_Tp* __ptr) const {
        static_assert(sizeof(_Tp) > 0, "can't delete pointer to incomplete
type");
        delete __ptr; }};

  template <class _Tp> 
    struct default_delete<_Tp[]> : public unary_function<_Tp*,void> {
      void operator()(_Tp* __ptr) const {
        static_assert(sizeof(_Tp) > 0, "can't delete pointer to incomplete
type");
        delete [] __ptr;}};

  template <class _Tp, size_t _Nm> 
    struct default_delete<_Tp[_Nm]> : public
binary_function<_Tp*,size_t,void> {
      void operator()(_Tp* __ptr, size_t) const {
        static_assert(sizeof(_Tp) > 0, "can't delete pointer to incomplete
type");
        delete [] __ptr;}};

The inheritance of unary/binary_function I think should be removed however
(if users rely on result_type etc. being defined, their code becomes
non-portable). It seems like a good idea to me to reuse the default_deleter
for shared ptr but I'm not sure if its fit to do so. What changes would be
required for it to be useable as a default for shared_ptr? Is there a way to
hide that from users?


Jonathan Wakely-4 wrote:
> 
> The previous question becomes moot if you do away with _Sp_deleter. Is
> it worth optimising for the common case of no deleter (which implies
> no allocator) by providing a new template:
> template <typename _Tp, typename _Lp>
>     class _Sp_counted_ptr;
> as well as the more general
> template <typename _Tp, typename _Deleter, typename _Alloc, typename _Lp>
>     class _Sp_counted_base_impl;
> (I don't like the name "base_impl" for a derived class, so have
> actually renamed this _Sp_counted_deleter)
> Both inherit from _Sp_counted_base but the first one is simpler and
> doesn't need to store either a deleter or allocator (the second can
> only use the EBO for either the deleter or allocator, not both, so
> takes more space on the heap.) 
> 

I also added EBO to the current tuple implementation and in unique_ptr<T,D>
I use a tuple<T*,D> as a container. If D is_empty then
sizeof(unique_ptr<T,D>) == sizeof(T*). Can shared_ptr use this with the
allocator as well? Store all three as tuple<T*,D,A> ? (you can find a patch
here http://blog.tripthelight.net/tuple-ebco.patch if you want to play
around with it)

Cheers
Chris

-- 
View this message in context: http://www.nabble.com/n2351%3A-Improving-shared_ptr-for-C%2B%2B0x-tf4291362.html#a12273580
Sent from the gcc - libstdc++ mailing list archive at Nabble.com.