QtCS2017 QtCore

From Qt Wiki
Revision as of 09:26, 9 October 2017 by Thiago Macieira (talk | contribs) (Created page with "== Intro == Suggested topics: * hashing function update; expanding the hash seed to 64- or 128-bit; adding std::hash for Qt types * QIODevice for Qt 6 Move to the containers...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Intro

Suggested topics:

  • hashing function update; expanding the hash seed to 64- or 128-bit; adding std::hash for Qt types
  • QIODevice for Qt 6

Move to the containers session:

  • use qssize_t

Quick conclusions:

  • QRandomGenerator and providing a PRNG of good quality (Mersenne Twister or Chacha20)
    • Yes if our compilers support


Use of standard C++ API

We will not add compilers that are worse than what we have today.

  • If all the compilers we have support things like std::mersenne_twister, then all will
  • We can add hard-fail configure test
  • Should we start migrating from QSharedPointer to std::shared_ptr?
    • Deprecate
    • Deprecate QScopedPointer
  • What about API from C++17/20 that we'd like to use?
    • Try to backport the API into a QtPrivate namespace (if it's been standardised) unless we want to add significant functionality a la QStringView
    • If it's not standardised yet, use Qt-style naming
  • API naming
    • std:: API naming is subtly different from Qt API (hopefully nothing that is confusing or misleading)
    • We could try to create wrappers (container.empty() → container.isEmpty())

Modifiers vs getters for QString/QStringView/QByteArray

We don't want people to write:

 str = std::move(str).simplified()

We want instead:

 str.simplify()

So we want to add the full set of modifiers.

Do we want to add freestanding functions that may operate on std::string and other string types?

  • Like qSimplify()
  • Polluting namespace
  • They'd all need to be inline and some could be big
  • freestanding brings in ADL and could introduce unexpected isues
  • We think members are cleaner and we don't want to add these
  • 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

QStringView

  • NEVER return QStringView (but QRegularExpression wants to)
    • Consequence of "never return a reference" (but containers do)
    • Lifetime issues
   auto s = lineedit.text().left(n);
   s valid?
  • We can be flexible on having exceptions:
    • The API needs to be specifically designed for dealing with references
    • Clear naming, such as QRegularExpression::captureView()

Discussion not finished