QtCS2017 QtCore: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "== Intro == Suggested topics: * hashing function update; expanding the hash seed to 64- or 128-bit; adding std::hash for Qt types * QIODevice for Qt 6 Move to the containers...")
 
No edit summary
Line 12: Line 12:




=== Use of standard C++ API ===
== Use of standard C++ API ==
We will not add compilers that are worse than what we have today.
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
* If all the compilers we have support things like std::mersenne_twister, then all will
Line 26: Line 26:
** We could try to create wrappers (container.empty() → container.isEmpty())
** We could try to create wrappers (container.empty() → container.isEmpty())


=== Modifiers vs getters for QString/QStringView/QByteArray ===
== Modifiers vs getters for QString/QStringView/QByteArray ==
We don't want people to write:
We don't want people to write:
   str = std::move(str).simplified()
   str = std::move(str).simplified()
Line 47: Line 47:
*** But review the changes to see what our arguments were on making them public
*** But review the changes to see what our arguments were on making them public


=== QStringView ===
== QStringView ==
* NEVER return QStringView (but QRegularExpression wants to)
* NEVER return QStringView (but QRegularExpression wants to)
** Consequence of "never return a reference" (but containers do)
** Consequence of "never return a reference" (but containers do)

Revision as of 09:41, 9 October 2017

Intro

Suggested topics:

  • hashing function update; expanding the hash seed to 64- or 128-bit; adding std::hash for Qt types
  • QIODevice for Qt 6

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


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