Date: Sun, 13 Sep 2020 09:46:45 -0400
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_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
Received on 2020-09-13 08:46:59