QtCS2017 QtCore

From Qt Wiki
Jump to: navigation, search

Intro

Suggested topics:

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

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
  • hashing function update:
    • Use SipHash-1-2, benchmark 32-bit SipHash
    • See if Allan is interested in implementing with ARM AES


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

Containers

You cannot have all three:

  1. Implicit sharing
  2. Performance
  3. Data-compatibility with std:: containers

QList:

Conclusions:

  • If we have QStringView, QArrayView, QByteArrayView, we don't need fromRawData()
  • We use qssize_t everywhere
  • Investigate C++ contract assertions

Containers relevant:

  • QArrayData-based containers: QString, QByteArray, QVector
    • Backed by the same template implementation (QArrayDataPointer)
    • They grow to 3*sizeof(void*): {d pointer, begin pointer, qssize_t };
    • Implementations:
   template<typename T> using QVector = QVectorImplementation<T, RefCounted>;
   template<typename T> using QExclusiveVector = QVectorImplementation<T, NotRefCounted>;
   QExclusiveVector v;
   v.resize(1024);
   auto ptr = v.data();
   // instead of: auto ptr = const_cast<QChar *>(v.constData())
   QVector v2 = std::move(v);
   v = std::move(v2);
  • QStringView
  • QHash, QMap
    • Wrapping std::{unordered_}map may be acceptable
    • Would we want to use qHash as the HashFunction with std::unordered_map?