kossebau added a comment.
Ah, I looked at the "dev" branch only and missed that it is possibly already
pre-Qt6, no longer base for any future Qt5 branches, right?
Indeed things look differently in the 5.15 branch, where the old variant is
tagged deprecated, I now see.
Have to tell that I am bit unhappy about what Qt devs are forcing us here
into then, only because we also want to support versions < 5.15:
assuming that all those `end` usages are correct and preferred, this code
here once ported to Qt6 should simply use `Qt::endl` again, right?
The only reason we do these changes here is to avoid deprecation warnings.
And I agree that doing any `#if QT_IS_VERSION_5_15 Qt::endl #ELSE endl
#ENDIF` sucks here, as there are too many instances and embedded too deep in
other expressions.
But now simply dropping the use of `endl` instead, so departing from a
well-known C++ code pattern, into doing lots of explicit calls (`<<
QLatin1Char('\n') + flush()`) makes the code worse IMHO.
No other idea what to do here yet. Perhaps we could instead do an alias
definition in each affected file instead, so having only one place with `#if
QT_IS_VERSION_5_15 Qt::endl #ELSE endl #ENDIF`. Like (untested sketched code):
namespace KF {
#if QT_VERSION >= QT_VERSION_CHECK(5, 15, 0)
QTextStream &endl(QTextStream &s) { return Qt::endl(s); }
#ELSE
QTextStream &endl(QTextStream &s) { return endl(s); }
#ENDIF
}
stream << "something for output" << KF::endl;
So the current logic with the known patterns could stay, and once KF6 is
created (so backward compat code can be dropped), things could be simply
changed to be just `Qt::endl`.
What do you think?
(I start to think that there are cases where having sub-version-level control
about deprecations warnings would be a reasonable feature...)
REPOSITORY
R269 BluezQt
REVISION DETAIL
https://phabricator.kde.org/D26320
To: mlaurent, dfaure
Cc: kossebau, apol, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham,
bruns
