> ** Wrapping std::{unordered_}map may be acceptable
Hmmm... from these benchmarks, QHash seems to regularly beat
std::unordered_map so is it really worth it ?
=> https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html
Besides, with the Qt implementation the performance is more-or-less
consistent across platforms ; if it were to use
std containers with moderately advanced algorithms, there could be much
more differences depending on the various implementations
(the worse offender being std::regex... these damn things just don't work
the same on any platform).
More generally, since all these containers are header-only due to their
templated nature, wouldn't it be interesting and benefiting to the greater
C++ community to
spin them off in their own small header-only utility library ?
Having an explicit choice between COW and no-COW would be valuable in many
places where people don't want to bring large stuff like whole QtCore but
where a few headers are OK imho;
offering facades to std:: types with easy, readable Qt-like APIs would also
be quite nice (ideally with a set of standard-compliant typedefs, eg
qt::hash_map... one can dream :p).
Best,
-------
Jean-Michaël Celerier
http://www.jcelerier.name
On Tue, Oct 10, 2017 at 2:49 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:
> [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
>
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
