This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [GSoC] __enable_shared_from_this_helper
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Tim Shen <timshen at google dot com>
- Cc: Fan You <youfan dot noey at gmail dot com>, Tim Shen <timshen91 at gmail dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 30 Apr 2015 12:23:52 +0100
- Subject: Re: [GSoC] __enable_shared_from_this_helper
- Authentication-results: sourceware.org; auth=none
- References: <CALvpekGVZEMtGN5MKVXrArG5cKJhqDQjsfgjdFZYk0=H=7+V_Q at mail dot gmail dot com> <20150428215024 dot GF3618 at redhat dot com> <20150428215349 dot GG3618 at redhat dot com> <CALvpekGhEJfEWdHmtOyco-Ua=sPjk4yhpFFE7Fzffy9cTmnVbA at mail dot gmail dot com> <CAG4ZjN=a9nvQ3CgqRiSze-fbUvh0u69WQQdehS5+mFXsvtSP=A at mail dot gmail dot com> <20150429100344 dot GH3618 at redhat dot com> <CAG4ZjNnFTOtEoSPdzv9Dip8s7O6o4ToL2+N-j_oEuxvrD1spLA at mail dot gmail dot com>
On 29/04/15 20:28 -0700, Tim Shen wrote:
Is it still as usable if we do a rebind here? [17.6.3.5] seems to make
rebind optional, and there may not exist a char allocator. This was my
major concern.
All allocators must support rebinding. If they don't provide a rebind
member then allocator_traits will provide it, and if that doesn't work
it's ill-formed and the allocator can't be used with allocate_shared.
Allocators are allowed to restrict the types they can be instantiated
with, so Alloc<char>::allocate() or Alloc<char>::deallocate() might
fail to compile, but that's not our problem. Users who define
allocators like that can't use them with allocate_shared<T[]>.
But yeah, for implementing 2) you still need to propagate the length.
Why? Am I missing something?
No, it's me who missed something, since I didn't fully follow your
pre-GSoC communications :) I'm not sure how well Fan is on track? Can
Fan briefly illustrate your progress?
As Jon explained, we don't need to explicitly pass around the length,
as long as a customized deleter can take care of it.
Yes, a custom deleter *must* be able to take care of it, because only
the pointer is passed to the deleter.
If the array was actually created by calling a.allocate(n) on some
allocator then n must be stored in the deleter, so it's not
shared_ptr's responsibility to store it.