QtCS2017 QtCore

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:

• QUIP 9

Conclusions:

• If we have QStringView, QArrayView, QByteArrayView, we don't need fromRawData()
• We use qssize_t everywhere
  • Check if we want to rename it to "qssize" (bikeshed warning!)
• 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?