[PATCH] Do not use tuple-like interface for pair in unordered containers
François Dumont
frs.dumont@gmail.com
Wed Aug 11 12:48:39 GMT 2021
Hi
Sorry for the delay, I had just miss this message.
I think you are clearly more expert than me for the changes you
propose. I had a look at the patch and it seems just fine as it keeps
the forwarding as expected. Nice simplification in
_NodeBuilder<_Select1st>, we indeed only need to deal with std::pair
type in this case.
François
On 26/07/21 7:25 pm, Jonathan Wakely wrote:
> On 23/07/21 19:21 +0100, Jonathan Wakely wrote:
>> I've been experimenting with this patch, which removes the need to use
>> std::tuple_element and std::get to access the members of a std::pair
>> in unordered_{map,multimap}.
>>
>> I'm in the process of refactoring the <utility> header to reduce
>> header dependencies throughout the library, and this is the only use
>> of the tuple-like interface for std::pair in the library.
>>
>> Using tuple_element and std::get resolved PR 53339 by allowing the
>> std::pair type to be incomplete, however that is no longer supported
>> anyway (the 23_containers/unordered_map/requirements/53339.cc test
>> case is XFAILed). That means we could just define _Select1st as:
>>
>> struct _Select1st
>> {
>> template<typename _Tp>
>> auto
>> operator()(_Tp&& __x) const noexcept
>> -> decltype(std::forward<_Tp>(__x).first)
>> { return std::forward<_Tp>(__x).first; }
>> };
>>
>> But the approach in the patch seems OK too.
>
> Actually I have a fix for PR 53339 so that we can support incomplete
> types again. So we don't want to access the .first member in the
> return type, as that requires a complete type.
>
More information about the Libstdc++
mailing list