QtCS2024 std::format: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
Ivan.solovev (talk | contribs) 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
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.