Re: transparent proxy of string_view as key for associative containers.

["François Dumont" <frs.dumont@gmail.com>]

Hi

     Just for information I am starting the work on this following this 
paper: http://wg21.link/p1690r1

François

On 16/11/20 10:57 am, Jonathan Wakely via Libstdc++ wrote:
> On 16/11/20 08:26 +0100, Daniel Krügler via Libstdc++ wrote:
>> Am Mo., 16. Nov. 2020 um 07:44 Uhr schrieb sotrdg sotrdg via Libstdc++
>> <libstdc++@gcc.gnu.org>:
>>>
>>> The code fails to compile for both unordered_map and map. Is this a 
>>> bug of libstdc++ or a defect of WG21?
>>> #include<unordered_map>
>>> #include<string>
>>> #include<string_view>
>>> #include<map>
>>>
>>> int main()
>>> {
>>> std::unordered_map<std::string,std::string> umap;
>>>                 std::string_view key{"a key"};
>>>                 auto p{umap.find(key)};
>>>                 std::map<std::string,std::string> map;
>>>                 auto p1{map.find(key)};
>>> }
>>
>> I don't see any WG21 defect involved here, but a mislead user 
>> expectation:
>>
>> Let's start with the observation that this code isn't valid. To
>> activate transparent comparison, you need to provide function objects
>> that have the is_transparent tag defined, e.g. aomething like the
>> following should be more appropriate:
>>
>> #include<unordered_map>
>> #include<string>
>> #include<string_view>
>> #include<map>
>>
>> struct hash_transparent
>> {
>>    using is_transparent = void;
>>
>>    template<class T>
>>    std::size_t operator()(const T& s) const
>>    {
>>        return std::hash<T>()(s);
>>    }
>> };
>>
>> int main()
>> {
>>    std::unordered_map<std::string, std::string, hash_transparent,
>> std::equal_to<>> umap;
>>    std::string_view key{ "a key" };
>>    auto p{umap.find(key)};
>>    std::map<std::string, std::string, std::less<>> map;
>>    auto p1{map.find(key)};
>> }
>>
>> Nonetheless, when you test this, you will still get a compile error
>> with gcc/clang for the unordered_map (Not for the map), so I'm
>> assuming that this feature has not been implemented yet.
>
> Correct.
>
>
>