transparent proxy of string_view as key for associative containers.

transparent proxy of string_view as key for associative containers.

[sotrdg sotrdg]

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)};
}
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

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

[Daniel Krügler]

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. Visual Studio
2019 accepts that code, though.

- Daniel

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

[Jonathan Wakely]

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.

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

[François Dumont]

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.
>
>
>

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

[Ville Voutilainen]

On Sat, 28 Nov 2020 at 13:02, François Dumont via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> Hi
>
>      Just for information I am starting the work on this following this
> paper: http://wg21.link/p1690r1

Thanks for the heads-up, because I was about to start doing that. All
yours, go ahead, I'll hack on something else.

I took a brief look at this, and we basically need to add the
templated overloads all the way down to the hash table,
but other than that, there doesn't seem to be anything too tedious in this.

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

[François Dumont]

On 28/11/20 12:17 pm, Ville Voutilainen wrote:
> On Sat, 28 Nov 2020 at 13:02, François Dumont via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
>> Hi
>>
>>       Just for information I am starting the work on this following this
>> paper: http://wg21.link/p1690r1
> Thanks for the heads-up, because I was about to start doing that. All
> yours, go ahead, I'll hack on something else.
>
> I took a brief look at this, and we basically need to add the
> templated overloads all the way down to the hash table,
> but other than that, there doesn't seem to be anything too tedious in this.

Yes, this is why I plan to give it a try :-)

And also because I think it is interesting to do so before continuing on 
PR96088:

https://gcc.gnu.org/pipermail/libstdc++/2020-October/051255.html