Details
-
Suggestion
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
None
-
None
-
af8f9a2a6 (dev)
Description
QStringBuilder has seen quite a few years of service and its edges should be well-rounded by now. I think it's time to think about ditching the classical operator+ for string-ish-es and only maintain the QStringBuilder-based operators.
The advantages
- QStringBuilder needs only O(N) functions in the number of supported types, classical op+ needs O(N²), even with C++20 magic
- only ¼ of testing needed d/t only one combination as opposed to four
- already now, op% can concatenate many more types than op+
- better performance than nested op+'s
The disadvantages:
- SiC for certain types of assignment
- auto problem (Clazy already warns, IIRC), which can be solved by implementing
QTBUG-99291
So while this may not be possible within Qt 6, we should definitely keep it in mind for Qt 7.
Attachments
Issue Links
- relates to
-
QTBUG-117699 QStringBuilder: one more problem with 'auto'
- Reported
-
QTBUG-74873 Make QStringBuilder default on Qt6
- Closed
-
QTBUG-99291 As a user of QStringBuilder, I would like the system to pin down rvalues, like QStringTokenizer does
- Closed