This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Possible bug in shared_ptr(unique_ptr) constructor?
- From: Brad Spencer <spencer at starscale dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 7 Oct 2013 18:34:16 -0300
- Subject: Re: Possible bug in shared_ptr(unique_ptr) constructor?
- Authentication-results: sourceware.org; auth=none
- References: <20131007123915 dot GA11628 at starscale dot com> <CAH6eHdQFFO8EXFNavumHguHs5-wtDaDtJ=0kvY7E_WNHqydTrw at mail dot gmail dot com> <CAH6eHdRb-4nL-z7LZdLBwyjJHYY74NTCXDYJhcBaHeZLXzvC0g at mail dot gmail dot com>
On Mon, Oct 07, 2013 at 05:09:19PM +0100, Jonathan Wakely wrote:
> > Yes, I think so - please report it to Bugzilla and CC me, I'll analyse
> > it properly and deal with it asap.
Sorry for the delay. Bug 58659 filed and you CCed.
> And here's a suggested patch to fix it:
I hacked in the patch to my installed toolchain headers and both my
minimal test case and real program worked as expected. I'll do a full
toolchain rebuild now with the patch. Thanks!
BTW, I noticed that when it's created from unique_ptr, shared_ptr uses
_Sp_counted_deleter even in the cases where the deleter is the
std::default_delete<T>. Since _M_del is just a normal member of
_Sp_counted_deleter (no empty base optimization, etc.), does this mean
that a shared_ptr made from a unique_ptr uses a slightly larger than
necessary count object? Is it worth trying to use _Sp_counted_ptr in
that case?
(I feel greedy for even asking.)
--
Brad Spencer