This is the mail archive of the
mailing list for the GCC project.
Re: Fix move_if_noexcept usages in _Hashtable
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 4 Dec 2018 14:38:36 +0000
- Subject: Re: Fix move_if_noexcept usages in _Hashtable
- References: <firstname.lastname@example.org>
On 04/12/18 07:45 +0100, François Dumont wrote:
This patch fix a minor problem with usage of std::move_if_noexcept.
We use it to move node content if move construtor is noexcept but we
eventually use the allocator_type::construct method which might be
slightly different. I think it is better to check for this method
This is likely to pessimize some code, since most allocators do not
have an exception-specification on their construct members.
Moreover I have added a special overload for nodes containing a
std::pair. It is supposed to allow move semantic in associative
containers where Key is stored as const deleting std::pair move
constructor. In this case we should still move the Value part.
It doesn't work for the moment because the std::pair piecewise
constructor has no noexcept qualification. Is there any plan to add it
? I think adding it will force including <tuple> in stl_pair.h, is it
If this evolution is accepted I'll adapt it for _Rb_tree that has
the same problem.
Working on this I also notice that content of initialization_list is
not moved. Is there a plan to make initialization_list iterator type
like move_iterator ? Should containers use
Whether to allow moving from std::initializer_list is an active topic,
Tested under Linux x86_64 normal mode.
Ok to commit this first step ?
No, this is not suitable for stage 3. It seems too risky.
We can reconsider it during stage 1, but I'd like to see (at least) a
new test showing a bug with the current code. For example, a type with
a move constructor that is noexcept, but when used with a
scoped_allocator_adaptor (which calls something other than the move
constructor) we incorrectly move elements, and lose data when an