unordered set design modification

Jonathan Wakely jwakely.gcc@gmail.com
Tue Oct 23 22:28:00 GMT 2012


On 23 October 2012 23:16, Jonathan Wakely wrote:
> On 23 October 2012 20:32, François Dumont wrote:
>>>
>>     I use default at the first place but then preferred to make
>> implementation explicit, not yet accustom to default keyword perhaps. If
>> using default is preferred then ok, I will in next patch. Does it really
>> work for move operations ? If I write it like that:
>>
>> unordered_set(unordered_set&&) = default;
>
> Yes, it works fine.  It also has the huge benefit that if the
> underlying operations are noexcept then the defaulted function is also
> noexcept.  If you define the function yourself then you need to
> determine and define its exception specification manually.  I suspect
> missing noexcept guarantees on hashtable is the cause of PR 55043.  I
> suggest defining those functions as defaulted so we only have to fix
> the exception specifications in one place.

Yes, as I suspected PR 55043 is due to missing exception
specifications. Adding 'noexcept' to _Hashtable(_Hashtable&&) allows
the testcase in the PR to compile, but changing it to unordered_set
causes it to fail again, because unordered_set(unordered_set&&) is not
noexcept.  Explicitly defaulting unordered_set&&) fixes it.

For now, just adding noexcept to _Hashtable and to each of the
unordered containers would work, but when we support allocator
propagation in those containers the exception specifications become
much more complicated and are conditional on the allocator type.  If
you want to make the implementation of those special member functions
explicit then you also have to make the exception specification
explicit, which is harder to get right.

Asking the compiler to generate the members for you (by defining them
as defaulted) will generate them optimally in most cases, so there is
no chance to define them incorrectly.



More information about the Libstdc++ mailing list