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.


  In D26320#586935 <https://phabricator.kde.org/D26320#586935>, @mlaurent wrote:
  
  > So what I need to change in this patch ? (if I need to change a code :) )
  
  
  When it comes to me, so far I have been more curious what the best principled approach is in general to react to the deprecation challenge we have here.
  And what the perfect streaming code would look like in general, now that we are touching this code.
  
  As said initial, I am used to the pattern to "<< endl" everywhere and assume some others are as well. Having now code doing all kind of custom linebreaks and flushing only when thinking it is needed or relying on auto-flush in other cases by destructors makes things seem more complicated to me, because less patterns and more chances to miss some flushing were perhaps needed. Also more lines of code, as the flush call is on a separate line usually.
  
  I may be more sensitive here when it comes to code structure patters, so will not try to push/enforce my ideas here and just stick to having advertized the solution I find more elegant to counter the namespace change only, and not changing code logic for that, repeated again here:
  
    namespace KF { // if not already in custom namespace
    using TextStreamFunction = QTextStream& (*)(QTextStream&);
    #if QT_VERSION >= QT_VERSION_CHECK(5, 14, 0)
    constexpr TextStreamFunction endl = Qt::endl;
    #else
    constexpr TextStreamFunction endl = ::endl;
    #endif
    }
    // use KF::endl now, or stick with endl if already in custom namespace
  
  If you prefer moving away from endl instead, your choice, as you also do the work & patch, also do others seem okay with it as well, from what I saw by the reactions to the similar patches.

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/20200108/23669980/attachment.html>