[Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

[we combined the main and containers session; we did not have time for 
QIODevice]

== 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:
# Implicit sharing
# Performance
# Data-compatibility with std:: containers

QList:
*  [https://codereview.qt-project.org/194984 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!) : https://
codereview.qt-project.org/#/c/208050/
* 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?

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