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.


  Thanks. Okay, so the old symbol is still there, and with that info I looked some more, and indeed the ::endl symbol is not declared in the header qtextstream.h, but only defined (and exported) in the source file qtextstream.cpp. Having 3 variants now not make sense to me on first look, but perhaps a result of some incomplete approach in Qt 5.14... oh well...
  
  For Okteta I now went for this approach, which I find more elegant:
  
    using TextStreamFunction = QTextStream& (*)(QTextStream&);
    #if QT_VERSION >= QT_VERSION_CHECK(5, 15, 0)
    constexpr TextStreamFunction endl = Qt::endl;
    #else
    constexpr TextStreamFunction endl = ::endl;
    #endif
  
  No extra namespace here, as all code is already in some Okteta namespace, so the lines with the `endl` do not even have to be touched :)
  
  Whether `endl` is a proper call in such places is left for another investigation on its own.
  
  In D26320#585916 <https://phabricator.kde.org/D26320#585916>, @dfaure wrote:
  
  > I don't think a code generator needs to flush() many times along the way anyway. \n actually sounds more efficient.
  
  
  Do Qt experts have some numbers on the sizes before which flush() makes sense in general? I guess it varies on the actual QIODevice, and then with QFile perhaps on the actual filesystem/kernel/whatever?
  
  Also surprised to see the implementation do a ¸writeBuffer.replace(QLatin1Char('\n'), QLatin1String("\r\n"));¸for windows where I expected `endl` itself to care for it...

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/20200102/5c8fa8d8/attachment.html>