Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-99243

As a user of Qt, I'd like it to fully support C++20

    XMLWordPrintable

    Details

    • Type: Epic
    • Status: Open
    • Priority: P2: Important
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core: Other
    • Labels:

      Description

      There are three broad categories of this:

      • First and foremost, I would like my projects to compile in C+<ins>20 mode and not have Qt headers get in the way in any way. That means C</ins><ins>20 warnings and compile errors should be fixed at the very least in public and then private headers, but eventually also in the implementation.
      • Second, I would like Qt APIs to better interoperate with their std C</ins>+ counterparts. A successful example is making QMutexLocker a template and QMutex a Lockable}, so that now I can use QMutexLocker on a std::mutex as well as a std::unique_lock on a QMutex. A less successful example is requiring UTF-8 for const char* strings, but then not supporting u8"" in your APIs in C+<ins>20 mode.
      • Third, and this ties in with the second point somewhat, I'd like Qt to adopt new C</ins><ins>20 features. A good example here is QUtf8StringView, which essentially fixes the C</ins><ins>20 u8"" vs. const char * problem, if only you would use it in the API more. A less successful example is QFuture, which still isn't {{co_await}}able.

      This list is broadly in priority order.

      These issues are but a small subset of the problems. I've made this epic to track all the different issues that are necessary to make Qt 6 work well with C</ins><ins>20. I think, too, that Qt 5.15 should at least not get in the way when we use it in C</ins><ins>20 projects.

      The following C</ins><ins>20 language features don't seem to have any effect on Qt's implementation or APIs, so they haven't gotten their own epic (yet):

      The following C</ins><ins>20 library features don't seem to have any effect on Qt's implementation or APIs, so they haven't gotten their own epic (yet):

      • erase_if (defined(__cpp_lib_erase_if) && __cpp_lib_erase_if >= 202002, https://wg21.link/P1973, https://wg21.link/P1115): we already implement our own overloads of these functions according to the latest standard version
      • <bit> (defined(__cpp_lib_bit_ops), https://wg21.link/P0553 / defined(__cpp_lib_int_pow2), https://wg21.link/P0556, https://wg21.link/P1956): these functions have a certain overlap with our <QtAlgorithms> header, and, indeed, are already used in these. There were a few hickups because the <bit> functions treat pathological input differently from our traditional functions, but these were fixed AFAIR.
      • Smart pointer creation with default initialization (defined(__cpp_lib_smart_ptr_for_overwrite), https://wg21.link/P1020, https://wg21.link/P1973): Can't use, can't reimplement for internal use (q20), because it needs stdlib support
        • except std::make_unique_for_overwrite, which may make sense to implement in q20
      • Constexpr for <numeric> (defined(__cpp_lib_constexpr_numeric), https://wg21.link/P1645)

      Acceptance criteria for this epic: all the issues linked to it are fixed (or closed or re-linked to C</ins>+23).

        Attachments

          Issue Links

          For Gerrit Dashboard: QTBUG-99243
          # Subject Branch Project Status CR V

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              mmutz Marc Mutz
              PM Owner:
              Vladimir Minenko Vladimir Minenko
              RnD Owner:
              Alex Blasche Alex Blasche
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:

                  Gerrit Reviews

                  There is 1 open Gerrit change