Date: Sun, 13 Sep 2020 17:24:49 +0200
I agree with Nikolay ... One should not be able to compare two instances of
two different types.
But. Since you are NOT comparing fundamental types AND you are comparing
contents of two instances you are OK in some cases specifically for your
problem domain. The meaning of comparing sets is context-specific. A
caricatural example is "let us compare two databases" ... Why not? Perhaps
valid in some problem domains. Outside of std lib purpose, perhaps.
On Sun, 13 Sep 2020 at 16:04, Nikolay Mihaylov via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Here some examples:
>
> https://godbolt.org/z/reeTY5
>
> including:
>
> template<class T1, class A1, class T2, class A2>
> bool operator==(const std::basic_string<char, T1, A1> &a, const
> std::basic_string<char, T2, A2> &b){
> return strcmp(a.c_str(), b.c_str()) == 0;
> }
>
> however I don't think you should be able to compare these directly.
> is like comparing unsigned with float point or bool with int.
>
> Nikolay
>
> On Sun, Sep 13, 2020 at 4:47 PM Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sun, Sep 13, 2020 at 8:17 AM Robert Behar via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> currently I can't compare two strings with differing allocators.
>>>
>>
>> IIUC, you're complaining that
>> https://godbolt.org/z/db9MWW
>>
>> std::string a;
>> std::pmr::string b;
>> return a == b;
>>
>> does not compile, whereas
>>
>> return a == std::string_view(b);
>>
>> does compile.
>>
>> Marshall Clow's P0805 "Comparing Containers" would have fixed this
>> incidentally for std::vector == std::pmr::vector, as part of its larger
>> motivation of fixing vector<int> == vector<long>.
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0805r2.html
>>
>> But P0805 specifically says:
>> > I have not suggested changes to basic_string, because it does not use
>> lexicographical_compare, but delegates to a traits class.
>>
>> Also, P0805 seems to be motionless? The last update was in 2018, and it
>> didn't go into C++20.
>> From the private Committee notes, it appears to me that it collided
>> head-on with C++20 Ranges' notion of "constrained algorithms," where you're
>> not supposed to ever be able to compare T and U unless they have a
>> common_reference type, which is not true for e.g. `int` and `long`.
>>
>> So it might be useful to provide a very limited fork of P0805 that
>> - only permits different allocators, not different element types
>> - includes basic_string as well as all the STL containers
>>
>> my $.02,
>> –Arthur
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
two different types.
But. Since you are NOT comparing fundamental types AND you are comparing
contents of two instances you are OK in some cases specifically for your
problem domain. The meaning of comparing sets is context-specific. A
caricatural example is "let us compare two databases" ... Why not? Perhaps
valid in some problem domains. Outside of std lib purpose, perhaps.
On Sun, 13 Sep 2020 at 16:04, Nikolay Mihaylov via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Here some examples:
>
> https://godbolt.org/z/reeTY5
>
> including:
>
> template<class T1, class A1, class T2, class A2>
> bool operator==(const std::basic_string<char, T1, A1> &a, const
> std::basic_string<char, T2, A2> &b){
> return strcmp(a.c_str(), b.c_str()) == 0;
> }
>
> however I don't think you should be able to compare these directly.
> is like comparing unsigned with float point or bool with int.
>
> Nikolay
>
> On Sun, Sep 13, 2020 at 4:47 PM Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sun, Sep 13, 2020 at 8:17 AM Robert Behar via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> currently I can't compare two strings with differing allocators.
>>>
>>
>> IIUC, you're complaining that
>> https://godbolt.org/z/db9MWW
>>
>> std::string a;
>> std::pmr::string b;
>> return a == b;
>>
>> does not compile, whereas
>>
>> return a == std::string_view(b);
>>
>> does compile.
>>
>> Marshall Clow's P0805 "Comparing Containers" would have fixed this
>> incidentally for std::vector == std::pmr::vector, as part of its larger
>> motivation of fixing vector<int> == vector<long>.
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0805r2.html
>>
>> But P0805 specifically says:
>> > I have not suggested changes to basic_string, because it does not use
>> lexicographical_compare, but delegates to a traits class.
>>
>> Also, P0805 seems to be motionless? The last update was in 2018, and it
>> didn't go into C++20.
>> From the private Committee notes, it appears to me that it collided
>> head-on with C++20 Ranges' notion of "constrained algorithms," where you're
>> not supposed to ever be able to compare T and U unless they have a
>> common_reference type, which is not true for e.g. `int` and `long`.
>>
>> So it might be useful to provide a very limited fork of P0805 that
>> - only permits different allocators, not different element types
>> - includes basic_string as well as all the STL containers
>>
>> my $.02,
>> –Arthur
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-09-13 10:25:11