This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] libstdc++/66742 use allocators correctly in list::sort()
- From: Daniel KrÃgler <daniel dot kruegler at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 3 Jul 2015 18:56:50 +0200
- Subject: Re: [patch] libstdc++/66742 use allocators correctly in list::sort()
- Authentication-results: sourceware.org; auth=none
- References: <20150703155115 dot GK18520 at redhat dot com>
2015-07-03 17:51 GMT+02:00 Jonathan Wakely <email@example.com>:
> As well as reducing the number of lists we construct when sorting this
> also allows us to range-check and ensure we don't overflow the
> fixed-size array (we now get an exception if that happens, although
> that's probably not possible even on a 64-bit machine).
> Unfortunately this seems to hurt performance, presumably the extra
> indirections to the _ListSOrtBuf rather than just an array of lists
> confuse the optimisers.
> Does anyone see any better solution to this? (other than rewriting the
> whole sort function, which I think has been proposed)
I have not yet thought about better solutions, but:
- Isn't it necessary to cope with possibly final allocators when
unconditionally forming the derived member class
struct _Impl : allocator_type
? Maybe you could just define that as a non-deriving aggregate?