This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] PR libstdc++/79206 check string_view sizes in operator==
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 24 Jan 2017 14:16:28 +0000
- Subject: Re: [PATCH] PR libstdc++/79206 check string_view sizes in operator==
- Authentication-results: sourceware.org; auth=none
- References: <20170124120542.GA10349@redhat.com> <CAFk2RUbbTDQA9fsErya3Eoe9xSQMh6-bz6QkR=hhZCuAnixtbA@mail.gmail.com>
On 24/01/17 14:54 +0200, Ville Voutilainen wrote:
On 24 January 2017 at 14:05, Jonathan Wakely <email@example.com> wrote:
I've just committed this, and then noticed that we don't do the same
optimization for basic_string unless the char_type is char. Presumably
this is so that we do call basic_string::compare() and so call any
user-defined traits_type::eq() function (which is observable). I don't
think that's necessary, because the standard says operator== on
strings returns the result of lhs.compare(rhs) == 0, not that it's
"Equivalent to" such a call. As long as we give the right answer, I
don't think we need to make an explicit call to
basic_string::compare(). So maybe we want this for basic_string too.
We do want it for basic_string as well, I think. And while I doubt
of the standard is pedantically correct, I also think that the
standard is broken if it
doesn't allow this optimization, and the standard should be fixed in that case.
The new overload that only applies to character types was added to fix
PR 39207, which makes the same observation as the string_view PR I
just fixed. Paolo's patch fixing it confirms my presumption:
"Per the standard, in general the equality operator is required to
simply return string::compare."
Again, I think if the standard means operator== must be equivalent to
calling string::compare (including all visible side effects,
algorithmic complexity etc.) then it should use the magic words
"Equivalent to". It doesn't use those words, so my reading is that
what it's required to return is the same boolean value as you would
get from lhs.compare(rhs) == 0, by whatever means.
I'll raise a defect to clarify this. If LWG get the answer wrong and
say it does require a call to compare then I'll file another defect
saying it should be changed to:
"Equivalent to: lhs.size() == rhs.size() && lhs.compare(rhs) == 0;"
But I think fixing this for std::basic_string should wait for stage 1.
The basic_string_view fix I committed only touches TS & C++17 stuff.