Date: Sun, 13 Sep 2020 17:04:52 +0300
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
>
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
>
Received on 2020-09-13 09:05:32