On Fri, Jan 13, 2017 at 1:39 AM, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On 13 January 2017 at 08:01, Tim Song <t.canens....@gmail.com> wrote: >> On Thu, Jan 12, 2017 at 8:11 PM, Ville Voutilainen >> <ville.voutilai...@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.
But it must be in either the source or the destination, so any missing elements have to be in one of the 65 temporary lists. Is there a problem with just going through all of them and splicing the contents (if any) back to *this?
