QtCS2017 QtCore: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
(Added link to qssize_t rename proposal change)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Intro ==
== Intro ==
Suggested topics:
Suggested topics:
* hashing function update; expanding the hash seed to 64- or 128-bit; adding std::hash for Qt types
* QIODevice for Qt 6
* QIODevice for Qt 6
* adding std::hash for Qt types
* expanding the hash seed to 64- or 128-bit


Move to the containers session:
Move to the containers session:
Line 10: Line 11:
* QRandomGenerator and providing a PRNG of good quality (Mersenne Twister or Chacha20)
* QRandomGenerator and providing a PRNG of good quality (Mersenne Twister or Chacha20)
** Yes if our compilers support
** 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




Line 58: Line 62:


Discussion not finished
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?

Latest revision as of 08:31, 10 October 2017

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?