QtCS2024 std::format: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
==Session Summary==
==Session Summary==
[[File:QtCS std format.pdf|thumb]]
In this session we'll discuss std::format and its support in Qt.
In this session we'll discuss std::format and its support in Qt.


Line 7: Line 8:
* Do we limit ourselves with the standard format specifiers, or do we allow custom specifiers?
* Do we limit ourselves with the standard format specifiers, or do we allow custom specifiers?
* Implementation details
* Implementation details





Latest revision as of 14:41, 5 September 2024

Session Summary

QtCS std format.pdf

In this session we'll discuss std::format and its support in Qt.

We'll try to discuss sevaral main questions:

  • Which Qt types should support formattings with std::format?
  • Do we limit ourselves with the standard format specifiers, or do we allow custom specifiers?
  • Implementation details


Bonus topic:

Do we need an alternative to QString::arg() with std::format-like syntax?

Session Owners

Ivan Note taker: Thiago

Notes

  • We would like to have support for std::format for our printable types (already supported in QDebug) so users don't have to define them locally
    • would clash later if we decided to add them
  • Does it make sense for all types?
    • QDebug can print almost anything but doesn't guarantee what it will print (it just has to be useful)
    • Should std::format reuse all of that? Should we guarantee what the output will be and retain it? Might make it impossible to use QDebug instead.
  • Marc suggests instead focusing on types that have equivalents in the Standard Library and document their behaviour & flags
    • Strings, floats, containers, geometric types, date/time
    • We gain experience in the process
    • We can reuse the QDebug code on a case-by-case basis. We can revisit the decision to use QDebug throughout later.
  • Can the output be lossy?
  • Headers: <format> is somewhat heavy, we shouldn't #include everywhere
    • But this means users wouldn't know the formatters exist and may go on to define their own implementatoins
    • Is this a big deal? Would users not realise that the code exist?
    • Suggestion: we put it in the classes' own headers and add a #define to disable the content, to improve compilation times
      • May not help, because the implementation of (for example) <chrono%gt; may bring in std::format

Formatting to QString

The Standard Library seems to be designed so we can provide our own destination format. Requires exploration.

Misc

Should we have a qDebug with std::format-style patterns?

Trivia: why does QTest's QCOMPARE print C++-escaped strings? So you can QCOMPARE to a dummy string, then copy the output verbatim to your source code.