QtCS2024 std::format: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
Ivan.solovev (talk | contribs) No edit summary |
||
(One intermediate revision by one other user not shown) | |||
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 | ||
Line 15: | Line 17: | ||
==Session Owners== | ==Session Owners== | ||
Ivan | Ivan | ||
Note taker: Thiago | |||
==Notes== | ==Notes== | ||
Line 23: | Line 26: | ||
** QDebug can print almost anything but doesn't guarantee what it will print (it just has to be useful) | ** QDebug can print almost anything but doesn't guarantee what it will print (it just has to be useful) | ||
** Should <tt>std::format</tt> reuse all of that? Should we guarantee what the output will be and retain it? Might make it impossible to use QDebug instead. | ** Should <tt>std::format</tt> 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: <tt><format></tt> is somewhat heavy, we shouldn't <tt>#include</tt> 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 <tt>#define</tt> to disable the content, to improve compilation times | |||
*** May not help, because the implementation of (for example) <tt><chrono%gt;</tt> 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. | |||
[[Category:QtCS2024]] | [[Category:QtCS2024]] |
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.