QtCS2024 std::format: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Updated session summary)
No edit summary
 
(2 intermediate revisions 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 14: Line 16:


==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>&lt;format&gt;</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>&lt;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

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.