D26320: endl is Qt:: namespaced in qt5.15. Port to \n and flush when QTextStream is not on a QFile

[Friedrich W. H. Kossebau]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200101/8074c45a/attachment.html>