Re: unordered set design modification

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 23 October 2012 20:32, François Dumont wrote:
>>
>> Do these comments work correctly?
>> I think it needs to be ///@{ for Doxygen to recognise it.
>
> I know only a little about Doxygen and only use copy/paste like you already
> noticed to try to respect its grammar.

OK, no problem.  I see it's like that everywhere else so either it
works, or we can deal with it separately.

>>> I will now take care of unordered_map and unordered_multimap.
>>
>> Thanks.
>>
>> It occurs to me now that the copy and move operations could be
>> defaulted, since all they do is forward to the member, which is both
>> copyable and movable.
>>
>     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.

> or even if I write it like that:
>
> unordered_set(unordered_set&& __x) = default;
>
> that is to say with a named parameter.

Yes, that works fine too.  IMHO it's stylistically ugly, why name a
parameter that isn't needed? If you need a named parameter for doxygen
to refer to then it could be useful, but my preference for a doxygen
comment on a defaulted move constructor would be simply:

/// Move constructor.

That should be sufficient, and doesn't ned to refer to @a __x.