Fwd: [GSoC] __enable_shared_from_this_helper

[Fan You <youfan dot noey at gmail dot com>]

---------- Forwarded message ----------
From: Fan You <youfan.noey@gmail.com>
Date: 2015-05-01 1:56 GMT-04:00
Subject: Re: [GSoC] __enable_shared_from_this_helper
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Tim Shen <timshen@google.com>, Tim Shen <timshen91@gmail.com>,
libstdc++ <libstdc++@gcc.gnu.org>


To conclude:

1. What should I do is to create a new class _Sp_counted_array by
merging _Sp_counted_ptr and _Sp_counted_deleter.
So, some design like this?
  template<typename _Ptr, typename _Deleter, typename _Alloc>
    class _Sp_counted_array : public _Sp_counted_base {
    public:
      // implement here
      using _Tp = typename std::remove_pointer<_Ptr>::type;
    private:
      _Tp _array[];   // do init in ctor
      size_t _size;
      _Alloc _alloc;
      _Deleter _del; // may use ebo to reduce size
    };

Then, change __shared_count accordingly, others can remain unchanged.

2. Usage you mentioned
>
>  shared_ptr<int[]> p(new int[3]);
>
> The shared_count only needs to allocate/deallocate a
>
> _Sp_counted_array<int> in both cases, and that has a known size.

How can  _Sp_counted_array<int> get the size when user didn't even pass one?

3. Actually it reminds me that user can use current std::shared_ptr
with array as long as the right deleter are provided.
>
>  #include <memory>
>
>  int main()
>  {
>    int array[3];
>    std::shared_ptr<int[3]> p(&array, [](void*){});
>  }


This will work because the _Tp = int[3] in original shared_ptr
implementation. But the new implementation, which, _Tp = int; So, I am
still not sure why size is not needed to be pass to _Sp_counted_array.
>
> shared_ptr<int[3]> p(new int[3]);

Didn't specify the size but it do tell you by using int[3] as template
parameter.

2015-04-30 13:48 GMT-04:00 Jonathan Wakely <jwakely@redhat.com>:

> On 30/04/15 10:41 -0700, Tim Shen wrote:
>>
>> This is why I was asking "still as usable". This feature actually
>> requires more from the user, since standard didn't specify more.
>>
>> Anyway, we don't need to worry about this for now.
>
>
> No, we don't have to worry about it ever. Period.
>
> Allocators that only support allocating some types cannot be used in
> arbitrary places in the library. That is already true for all the
> node-based containers and for std::allocate_shared and lots of other
> places that rely on rebinding allocators.
>
> We do not have to (and *cannot*) support allocators that can't be
> rebound to arbitrary types. That's not a problem that needs to be
> solved!