On 2017-11-30 20:09, Thiago Macieira wrote:
On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote:
What's wrong with str.compare()?
Do these two quotes somehow fit together?
template <StringLike LHS, StringLike RHS>
bool operator==(const LHS &lhs, const RHS &rhs)
{ return qCompareStrings(lhs, rhs) == 0; }
template <StringLike LHS, StringLike RHS>
bool operator==(const LHS &lhs, const RHS &rhs)
{ return lhs.compare(rhs) == 0; }
if (u"Hello" == string) ~~~
I don't see how this problem can't be solved. We don't need templates
with
StringLike concepts. Not to mention we can't really rely on them in Qt
for the
next 10 years, so if you want to write that last line of code, we'll
need a
solution without concepts.
Don't go off on a tangent here. I used concepts syntax to keep the
example simple. I can post with std::enable_if, if you prefer :)
Anyway, the point is the asymmetry of member functions.
u"Hello".compare(string) does not compile in C++ (it does in Java), so
everyone that wants to write a template like the op== above will have to
re-invent qCompareStrings(). The Qt API rules stipulate that the common
use case should be made simple (we do, we have member functions
whereever we can add them), but make the rest possible. And that's where
qCompareStrings() come in. It makes the remaining 5% (random number)
possible.
2. So ok, performance matters. But a flexible interface matters too.
You
might not use compile-time string manipulation, but people do. They
write compile-time JSON parsers. Anyway, assuming you are right (and I
don't think you are, here), where are your numbers that show that the
frequency of calls to the QStringView(Char*) ctor multiplied with the
performance increase of out-of-line SIMD code multiplied by the
average
length of strings is so large as to warrant dropping support for
compile-time string manipulations and std compatibility? Show them,
and
then we'll discuss it again.
IMNSHO, absent proof to the contrary, you are optimizing an edge case
here, an edge case that people can easily fix by using
auto s = QStringView{s, qustrlen(s)};
manually when they expect large strings. The missing constexpr is not
so
easily obtained than the SIMD length calculation.
This was a judgement call. The C++ standard needs to be fixed, so I am
doing
what I think is the correct direction: performance first.
And I would interpret the Qt API design rules differently: like
qCompareStrings(), constexpr QSV ctors enable the remaining 5% of
use-cases. If the standard equivalent wasn't constexpr all-over, one
could maintain that what people don't know they will not miss. But
std::string_view _is_ all-constexpr, and therefore (some) people will
miss it. That leaves the question whether long raw strings passed to
QSV(Char*) without also passing the length are the common use-case or
whether the common use-case is that the user doesn't care. And I think
that it's the latter, because off the top of my head, I can think of no
situation where I actually would need the length calculation in QSV's
ctor. The situation is a bit different in std::string_view where this
ctor also receives all C string literals. We have a separate ctor for
that in QSV, so we don't depend so existentially on the (Char*) ctor to
be constexpr, but we also don't have a performance problem, since the
frequency of calls to that ctor is very, very low. And there's the
work-around to enable the 10% (random number) of users that see a
performance problem with that ctor to call qustrlen() manually.
We should empower, not infantilise, the user.
API parallelism with the Standard Library is not required where the
standard
library makes mistakes. Requiring constexpr for calculating string
lengths is
one where I think it made a mistake. Therefore, I will not accept that
as an
argument.
We all think we're smarter than the committee, yes. Maybe we are, but
swarm intelligence suggests otherwise.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
