C++ Logo


Advanced search

Re: why does std::basic_string should accept an std::basic_string_view with the same charT and Traits

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
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

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

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,

Received on 2020-09-13 08:46:59