QtCS2024 std::format: Difference between revisions
Jump to navigation
Jump to search
(Created page with "==Session Summary== ==Session Owners== ==Notes== Category:QtCS2024") |
Ivan.solovev (talk | contribs) No edit summary |
||
(3 intermediate revisions by 2 users 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. | |||
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== | ==Session Owners== | ||
Ivan | |||
Note taker: Thiago | |||
==Notes== | ==Notes== | ||
* We would like to have support for <tt>std::format</tt> 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 <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.