This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH] PR libstdc++/78389
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: Tim Song <t dot canens dot cpp at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 13 Jan 2017 08:39:21 +0200
- Subject: Re: [v3 PATCH] PR libstdc++/78389
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUYmeFv5M4TX4_GuT71AVHaYLD=iXG7mzb+rYa+khoL-Vg@mail.gmail.com> <CAPQZVxtcQBh=WhioT_VNeY-heLBFyNGOhyt8WqtMnrbKPNzBBA@mail.gmail.com>
On 13 January 2017 at 08:01, Tim Song <t.canens.cpp@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> This patch doesn't try to fix the reported sort() issue, because
>> a) it would require undoing a throwing move operation, which
>> is impossible.
>> b) in order to avoid the throwing move, we would need to add a
>> level of indirection and the scratch space for the indirect data
>> would need to be allocated.
>
> Wait, what throwing move? list::sort should be all splicing and no
> moving, unless I missed something.
It operates based on merge, which moves elements from one list to
another using a throwing
comparator. Undoing that operation is fairly tricky, because I don't
know where the merged
items landed. Splice is another move operation, but in case of splice,
I would know where
the items land, and it also doesn't throw, but merge does.