[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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
