[Development] QtCS 2017 QtCore sessions

Thiago Macieira thiago.macieira at intel.com
Thu Nov 30 17:13:22 CET 2017


On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote:
> On 2017-10-10 14:49, Thiago Macieira wrote:
> [...]
> 
> > * We think members are cleaner and we don't want to add these
> 
> You have members where members are possible.
> But you can't add members to char16_t[]!

Why would we need to?

> > * However, we already have some of those! qStartsWith
> > ** Global namespace *and* documented
> > ** foo.startsWith(bar) vs qStartsWith(foo, bar)
> > ** Same conclusion, probably mark \internal, namespace them
> > *** But review the changes to see what our arguments were on making
> > them
> > public
> 
> I have seen that you used my recent absence to sneak in a change to put
> these functions into the QtPrivate namespace - in a public header! It's
> good that you agree that there should be free functions for them, it's a
> pity that you think you need to hide them.

I did not know you were absent when this was posted. Sorry, we cannot be held 
to blame for your employer deciding to suspend participation for a while. Qt 
development did not stop.

You'll note I had agreed with you when those functions came in. It was during 
the QtCore session at QtCS that when I brought them up, people cringed and 
asked whether it was the Qt-way. The conclusion was it wasn't, so I posted 
here *and* in the API review that we were going to change.

> No-one forces anyone to use them, but they are there for when you need
> them: for use in generic code, to have one syntax that works for every
> pair of arguments[1]. People are still free to use vec.begin(), and
> personally, I'll choose that every time over std::begin(vec), but
> std::begin() needs to be there, too. Same thing for qCompareStrings().

We just didn't want to make them officially part of the API.

> I will not restart work on QStringView before these are put back. So,
> please, restore them to the state they had[2], then I'll get approval
> for finishing the work on QStringView. If it's too late for 5.10, add
> them back as inline functions, calling the useless QtPrivate ones,
> please.

It's too late for 5.10, but we can add them as inline functions for 5.11, if 
there's strong reason.

I don't believe there is. The reason is still the same: we don't want them in 
the API.

> [1] e.g., at some point, we should make operator==(string-like,
> string-like) templated and just call qCompareStrings. There's no reason
> to hold this API from the user.

What's wrong with str.compare()?

> [2] incl., btw, the constexpr on QStringView(Char*), which is required
> for std::string_view compat:
> http://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view

Pity. Performance is more important than constexpr.

This stays until C++ allows us to overload constexpr and non-constexpr.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list