Re: [Development] Windows 7 support will be dropped in Qt 6
Volker Hilsheimer wrote: > Sounds like y’all have a wonderful new business opportunity ahead of > yourselves: charge your new-leaf-app-on-old-OS customers handsomely for > the extra effort. After all, you do have to keep your Windows 7 test rigs > around (and secured); perhaps even pay some extra retainers to those > developers on your team that know about those Windows 7 quirks. That can’t > be cheap in terms of net and esp opportunity cost! You are still stuck in the commercial world there. In the Free Software world, I run a shell script that builds an .exe with cross-MinGW(-w64) and an installer with cross-NSIS, and only if I'm really nice, I'll run the output with WINE once for a minute or two. Then I upload it. Testing is what I have users for. :-p Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Sounds like y’all have a wonderful new business opportunity ahead of yourselves: charge your new-leaf-app-on-old-OS customers handsomely for the extra effort. After all, you do have to keep your Windows 7 test rigs around (and secured); perhaps even pay some extra retainers to those developers on your team that know about those Windows 7 quirks. That can’t be cheap in terms of net and esp opportunity cost! Share some of the remaining profit with my employer to get access to the commercial-only 5.15 LTS releases. Cheers, Volker From: Development on behalf of Kevin Kofler Sent: Tuesday, June 16, 2020 1:36:54 AM To: development@qt-project.org Subject: Re: [Development] Windows 7 support will be dropped in Qt 6 Edward Welbourne wrote: > How many of those Win 7 users are routinely upgrading the software on > their systems ? Given that they're not updating the O/S, it seems > reasonable to presume that they are, at least, somewhat conservative > about upgrades; they don't want the shiny new features the folk you > dismiss as "cool kids" are upgrading for, so why would they care if the > Qt apps they're using are upgraded to Qt 6 ? Surely such conservative > users are likely to *prefer* to have such updates as they do take in > contain only security fixes - i.e. the sorts of change that happen on an > LTS version of Qt, rather than the radical change that comes with a new > major version. I cannot really know what goes in the mind of Windows users (as I cannot fathom why one would want to use that operating system to begin with), but at least here on GNU/Linux, it is a common request by users to want their core system to never change, but the latest applications on top of it. That, apparently contradictory, request is often hard to cater for, but it always keeps coming up (leading to ideas such as Fedora/RHEL Modularity, which come with their own can of worms, but that is not the topic here). So, if Windows users are anything like GNU/Linux users, they will definitely want the latest leaf applications on their old Windows 7, which implies also the latest Qt if those applications happen to use Qt. Unless, of course, the developers of the application never upgrade to Qt 6, but surely that cannot be your targeted outcome. Another possible outcome that I can imagine is somebody backporting the LGPL Qt 6 to Windows 7, which would not only be an enormous waste of developer effort (to basically readd all the compatibility code that you removed), but would also lead to a version of Qt circulating that you cannot quality- control (chances are that such a community port would have more bugs than an official port) nor sell commercial licenses for (chances are that the port would never get submitted under your CLA, since it is unlikely that a patchset reverting a deliberate upstream change would ever get merged). > For reference, at home I'm one of those conservative users - albeit on > Linux - using Debian/stable and often sliding into Debian/old-stable > rather than update, just because there's a newer stable available. I > like the stability and don't care so much about the shiny new things; so > don't try accusing me of looking down on those who stick with the tried > and trusted things they have; and don't try telling me that software > developers should make sure their newest versions work on those stable > systems, because I - like many such conservative users - don't want > shiny new versions, I only want security fixes to stable versions, > sacrificing shiny new features in favour of reliability. I can tell you from experience that, while truly conservative users like you definitely exist (it's not just you), there is also plenty of user demand for shiny new applications on a conservative base system. > That's adaptation by the app developers in their "new release" versions; > we understand perfectly well that app maintainers (in so far as *they* > care to continue supporting legacy versions of any O/S) also *want* to > have a stable version, whose security and stability they know well from > experience; which means sticking with LTS versions of the libraries they > use. Just as we have our stable branches and our shiny new version, app > maintainers who care about supporting legacy platforms used by > conservative users have their stable versions, that they maintain atop > stable versions of their prerequisites. That only works if you actually make your LTS versions available to the large community of Qt developers, most of whom use the LGPL version of Qt and cannot use commercial licenses for various reasons. If the plan to provide LTS versions only to commercial customers is implemented for 5.15 as planned, LTS will be completely useless to the vast majority of Qt developers. > If we *never* allow ourselves breaking changes, we'd still have a nice > stable product that worked great on an O/S or two from the last century. > Qt would thus be irrelevant.
Re: [Development] Windows 7 support will be dropped in Qt 6
Edward Welbourne wrote: > How many of those Win 7 users are routinely upgrading the software on > their systems ? Given that they're not updating the O/S, it seems > reasonable to presume that they are, at least, somewhat conservative > about upgrades; they don't want the shiny new features the folk you > dismiss as "cool kids" are upgrading for, so why would they care if the > Qt apps they're using are upgraded to Qt 6 ? Surely such conservative > users are likely to *prefer* to have such updates as they do take in > contain only security fixes - i.e. the sorts of change that happen on an > LTS version of Qt, rather than the radical change that comes with a new > major version. I cannot really know what goes in the mind of Windows users (as I cannot fathom why one would want to use that operating system to begin with), but at least here on GNU/Linux, it is a common request by users to want their core system to never change, but the latest applications on top of it. That, apparently contradictory, request is often hard to cater for, but it always keeps coming up (leading to ideas such as Fedora/RHEL Modularity, which come with their own can of worms, but that is not the topic here). So, if Windows users are anything like GNU/Linux users, they will definitely want the latest leaf applications on their old Windows 7, which implies also the latest Qt if those applications happen to use Qt. Unless, of course, the developers of the application never upgrade to Qt 6, but surely that cannot be your targeted outcome. Another possible outcome that I can imagine is somebody backporting the LGPL Qt 6 to Windows 7, which would not only be an enormous waste of developer effort (to basically readd all the compatibility code that you removed), but would also lead to a version of Qt circulating that you cannot quality- control (chances are that such a community port would have more bugs than an official port) nor sell commercial licenses for (chances are that the port would never get submitted under your CLA, since it is unlikely that a patchset reverting a deliberate upstream change would ever get merged). > For reference, at home I'm one of those conservative users - albeit on > Linux - using Debian/stable and often sliding into Debian/old-stable > rather than update, just because there's a newer stable available. I > like the stability and don't care so much about the shiny new things; so > don't try accusing me of looking down on those who stick with the tried > and trusted things they have; and don't try telling me that software > developers should make sure their newest versions work on those stable > systems, because I - like many such conservative users - don't want > shiny new versions, I only want security fixes to stable versions, > sacrificing shiny new features in favour of reliability. I can tell you from experience that, while truly conservative users like you definitely exist (it's not just you), there is also plenty of user demand for shiny new applications on a conservative base system. > That's adaptation by the app developers in their "new release" versions; > we understand perfectly well that app maintainers (in so far as *they* > care to continue supporting legacy versions of any O/S) also *want* to > have a stable version, whose security and stability they know well from > experience; which means sticking with LTS versions of the libraries they > use. Just as we have our stable branches and our shiny new version, app > maintainers who care about supporting legacy platforms used by > conservative users have their stable versions, that they maintain atop > stable versions of their prerequisites. That only works if you actually make your LTS versions available to the large community of Qt developers, most of whom use the LGPL version of Qt and cannot use commercial licenses for various reasons. If the plan to provide LTS versions only to commercial customers is implemented for 5.15 as planned, LTS will be completely useless to the vast majority of Qt developers. > If we *never* allow ourselves breaking changes, we'd still have a nice > stable product that worked great on an O/S or two from the last century. > Qt would thus be irrelevant. Nonsense. We would have a nice stable product that just works on old and new operating systems alike. New operating systems are either supported out of the box thanks to backwards compatibility, or support can be added without any breaking changes. Supporting a new operating system version does not require dropping support for older versions, and most definitely does not require the other (entirely unrelated) breaking changes (deprecations etc.) that are being implemented in Qt 6. > Just had a quick look at that issue [QTBUG-74687]; and I note that it > *didn't* ask your opinion, it set out to evaluate how practical it would > be to drop Win 7. Huh? How do you "evaluate how practical it would be to drop Win 7" WITHOUT
Re: [Development] First Qt6.0.0 Snaphot available
On Monday, 15 June 2020 09:37:31 PDT Alexandru Croitor wrote: > Thanks for the feedback. Usually Qt forces usage of the bundled 3rd party > libs via -qt-libpng flags, etc And that just goes to show why you shouldn't use those binaries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] ?==?utf-8?q? First Qt6.0.0 Snaphot available
On Monday, June 15, 2020 14:06 CEST, Jani Heikkinen wrote: > Hi Everyone, > > We have published first Qt6.0.0 snapshot today, see more info from Tuukka's > blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available Hi, is the source available somewhere? Can't find any 6.0 tarballs on download.qt-project.org yet. Would be nice to keep the snapshots in sync... ttyl bero ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] About Qt6 and qt-solitions repository
Hi list, I see more and more discussions about Qt6, and though what future will look like for qt-solutions [0] repo? It has some useful tools like qtservice and qtsingleapplication, though other "solutions" seems not really updated any more. Anyhow, I guess it's purely community effort to make any of this work with Qt6 (and CMake)? Maybe there should be qt6-solutions repo for Qt6 port? ..or just if-def'ing them to make work for Qt6 *and* Qt5, like it's also made to work with Qt4? [1] When writing CMakeLists.txt/.cmake, should "include/link [2] logic still be there? Also, what about configure script that asks about these two use cases? [3] Or maybe some one is already answered these questions and is planning to do any of this work? Thanks! [0] https://code.qt.io/cgit/qt-solutions/qt-solutions.git/ [1] https://code.qt.io/cgit/qt-solutions/qt-solutions.git/tree/qtservice/src/qtservice.cpp?id=7244e43695a8597bb14bf97b693536ba80a3dd03#n76 [2] https://code.qt.io/cgit/qt-solutions/qt-solutions.git/tree/qtservice/src/qtservice.pri?id=290bd1fd7d4ab837ad42e933518a1d08666a2cd8#n7 [3] https://code.qt.io/cgit/qt-solutions/qt-solutions.git/tree/qtservice/configure?id=5019ece540d1f9dc08157f67b55d1c4ed896ae39 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Hi Max, I get the issues as you present them. Why drop support for the 2nd most popular OS version out there?! This also doubles the effort required for Qt developers who want to target older systems with Qt 6 apps. That is certainly a pain point! There are couple more thoughts I've had after reviewing your excellent metrics. 1. Currently Win 7 usage is declining at a little over 1% per month based on the articles you shared. This indicates that by the time Qt 6.2 (the next LTS) is released next year, Win 7 usage will most likely drop below MacOS, and further, it will be mostly gone by the time 5.15 LTS support ends (IF trends continue). This leads me to believe that the majority of Qt app developers could safely branch, or else delay migration to Qt 6 for a few more months in order to give the majority of their customers time to move with the industry. As a cross-platform framework, we do have to consider the "most common" usage scenarios first. But I can tell you understand this. 2. It may be completely possible for customers to build a version of Qt that still works with Windows 7! The key point would be that the onus moves to the Qt developers who need this support to do their own build. This is extra effort, but there seem to be only a few particular APIs that Qt is looking to remove support for. If an app doesn't use these APIs, this would not be a problem. Or you could revert a few patches and do a custom build for Win7. Ok, 3 thoughts. I think it's worth noting in addition to what Eddy shared, the Qt team did a pretty decent job of responding to the concerns raised on that QTBUG in spite of the fact that it was not intended as a feedback mechanism. We recognize that any big shift in support causes pain for the development community. Some more than others. And yet, in order to move forward we must all face the pain of evolution (to wax a little philosophical ). Making the majority of these breaks happen with a Major version release makes the most sense as it consolidates this pain into one point in time hopefully making the OVERALL experience of developing and maintaining Qt projects over time, as smooth and painless as possible. Thanks again to all our great developers for all the insightful discussion shared here! Corey Pendleton Senior Solutions Engineer, Americas -Original Message- From: Development On Behalf Of Edward Welbourne Sent: Monday, June 15, 2020 5:35 AM To: Max Paperno Cc: development@qt-project.org; inter...@qt-project.org Subject: Re: [Development] Windows 7 support will be dropped in Qt 6 Max Paperno (13 June 2020 03:28) wrote: > I would restate my objection by pointing out again [1] that Win 7 is > still the 2nd most popular desktop OS in the world, with 3x more users > than all MacOS versions combined. Never mind Linux, which is on par > with Win XP users (the previous "known good" Windows version prior to > 7). How many of those Win 7 users are routinely upgrading the software on their systems ? Given that they're not updating the O/S, it seems reasonable to presume that they are, at least, somewhat conservative about upgrades; they don't want the shiny new features the folk you dismiss as "cool kids" are upgrading for, so why would they care if the Qt apps they're using are upgraded to Qt 6 ? Surely such conservative users are likely to *prefer* to have such updates as they do take in contain only security fixes - i.e. the sorts of change that happen on an LTS version of Qt, rather than the radical change that comes with a new major version. For reference, at home I'm one of those conservative users - albeit on Linux - using Debian/stable and often sliding into Debian/old-stable rather than update, just because there's a newer stable available. I like the stability and don't care so much about the shiny new things; so don't try accusing me of looking down on those who stick with the tried and trusted things they have; and don't try telling me that software developers should make sure their newest versions work on those stable systems, because I - like many such conservative users - don't want shiny new versions, I only want security fixes to stable versions, sacrificing shiny new features in favour of reliability. Meanwhile, at work, I use shiny new things so that I can deliver shiny new things to those who *do* want them; and I fix bugs in old things so that those who want stability get it. Because software developers should cater to what their users want - some of them care more about stability, others about shiny new things. In the end, giving the latter what they want today is the way to ensure the former get what they'll be wanting in a few years time (once the shiny new things have been tried, tested, fixed and made stable, while those using them have found which of them live up to their shininess and which fade too fast to be worth caring about). So we have stable versions and we make
Re: [Development] First Qt6.0.0 Snaphot available
> On 15. Jun 2020, at 18:01, Albert Astals Cid via Development > wrote: > > El dilluns, 15 de juny de 2020, a les 14:06:00 CEST, Jani Heikkinen va > escriure: >> Hi Everyone, >> >> We have published first Qt6.0.0 snapshot today, see more info from Tuukka's >> blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available >> >> Qt 6.0.0 snapshot can be found from 'Preview' category in Qt online >> installer/Maintenance tool. This snapshot is based on quite old content but >> we are planning to do silent updates occasionally so please also check >> updates now and then. > > The Linux packages are "incomplete" > libQt6Core.so.6.0.0 is linked against libdouble-conversion.so.1 > libQt6Gui.so.6.0.0 is linked against libpng15.so.15 > but neither of them are shipped > > So unless you're using the old RedHat that the binary packages have been > built > against, the binary packages are not very useful. > > You already ship libicu* so i guess you have a way of shipping non Qt libs > that are actually needed for the binary package to be actually binary/ > standalone. Hi Albert, Thanks for the feedback. Usually Qt forces usage of the bundled 3rd party libs via -qt-libpng flags, etc These snapshots were the first snapshots made with the CMake built Qt, and thus some of those options were missing. I've pushed a change to address that. https://codereview.qt-project.org/c/qt/qt5/+/304445 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] First Qt6.0.0 Snaphot available
El dilluns, 15 de juny de 2020, a les 14:06:00 CEST, Jani Heikkinen va escriure: > Hi Everyone, > > We have published first Qt6.0.0 snapshot today, see more info from Tuukka's > blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available > > Qt 6.0.0 snapshot can be found from 'Preview' category in Qt online > installer/Maintenance tool. This snapshot is based on quite old content but > we are planning to do silent updates occasionally so please also check > updates now and then. The Linux packages are "incomplete" libQt6Core.so.6.0.0 is linked against libdouble-conversion.so.1 libQt6Gui.so.6.0.0 is linked against libpng15.so.15 but neither of them are shipped So unless you're using the old RedHat that the binary packages have been built against, the binary packages are not very useful. You already ship libicu* so i guess you have a way of shipping non Qt libs that are actually needed for the binary package to be actually binary/ standalone. Cheers, Albert > > br, > Jani Heikkinen > Release Manager > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] First Qt6.0.0 Snaphot available
Hi Everyone, We have published first Qt6.0.0 snapshot today, see more info from Tuukka's blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available Qt 6.0.0 snapshot can be found from 'Preview' category in Qt online installer/Maintenance tool. This snapshot is based on quite old content but we are planning to do silent updates occasionally so please also check updates now and then. br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
Max Paperno (13 June 2020 03:28) wrote: > I would restate my objection by pointing out again [1] that Win 7 is > still the 2nd most popular desktop OS in the world, with 3x more users > than all MacOS versions combined. Never mind Linux, which is on par > with Win XP users (the previous "known good" Windows version prior to > 7). How many of those Win 7 users are routinely upgrading the software on their systems ? Given that they're not updating the O/S, it seems reasonable to presume that they are, at least, somewhat conservative about upgrades; they don't want the shiny new features the folk you dismiss as "cool kids" are upgrading for, so why would they care if the Qt apps they're using are upgraded to Qt 6 ? Surely such conservative users are likely to *prefer* to have such updates as they do take in contain only security fixes - i.e. the sorts of change that happen on an LTS version of Qt, rather than the radical change that comes with a new major version. For reference, at home I'm one of those conservative users - albeit on Linux - using Debian/stable and often sliding into Debian/old-stable rather than update, just because there's a newer stable available. I like the stability and don't care so much about the shiny new things; so don't try accusing me of looking down on those who stick with the tried and trusted things they have; and don't try telling me that software developers should make sure their newest versions work on those stable systems, because I - like many such conservative users - don't want shiny new versions, I only want security fixes to stable versions, sacrificing shiny new features in favour of reliability. Meanwhile, at work, I use shiny new things so that I can deliver shiny new things to those who *do* want them; and I fix bugs in old things so that those who want stability get it. Because software developers should cater to what their users want - some of them care more about stability, others about shiny new things. In the end, giving the latter what they want today is the way to ensure the former get what they'll be wanting in a few years time (once the shiny new things have been tried, tested, fixed and made stable, while those using them have found which of them live up to their shininess and which fade too fast to be worth caring about). So we have stable versions and we make new versions that break old stuff in order to deliver new things - and stay relevant. > Any software publisher not catering exclusively to the "cool kids" > with the "latest and greatest" mentality would be shooting themselves > in the foot by dropping Win 7 support at this point. That's millions > of potential users. Depending on one's market, of course. And Qt won't be dropping support for Win 7, it'll still be supported by 5.15, which will have the types of change that conservative users and sysadmins are willing to take in on the machines whose O/S they're not willing to upgrade. > I would bet Qt could save a lot more resources by dropping MacOS/Linux > support entirely. Not saying that's a good idea, but dropping the 2nd > most popular OS instead doesn't make any sense to me either. Any saving is only meaningful in terms of what it lets you get instead. A platform with more *users* isn't necessarily a platform with more downloads of software previously absent from that platform, or upgrades of software previously in use. A platform whose users routinely upgrade their O/S is also a platform on which one can reasonably expect users to routinely upgrade their other software. Numbers of users are only relevant via their contribution to numbers of downloads / installs / upgrades. > Yes, anyone needing to support Win 7 can still use Qt 5, which is > what's going to happen for several more years at least. ... and that's what most users of Win 7 are likely to want; the only updates they want are security fixes. If they wanted shiny new features, they'd be upgrading the O/S, too. > I though one of the goals for Qt 6 was quicker adaptation than the Qt > 4 -> 5 migration. That's adaptation by the app developers in their "new release" versions; we understand perfectly well that app maintainers (in so far as *they* care to continue supporting legacy versions of any O/S) also *want* to have a stable version, whose security and stability they know well from experience; which means sticking with LTS versions of the libraries they use. Just as we have our stable branches and our shiny new version, app maintainers who care about supporting legacy platforms used by conservative users have their stable versions, that they maintain atop stable versions of their prerequisites. > From this move, and everything I've seen discussed on the devs list > lately, I just don't see that happening. Seems like one breaking > change after another (even if each individual one is relatively minor, > they add up quickly). If we *never* allow ourselves breaking changes, we'd still have a nice stable
Re: [Development] Text streaming interface & function_view
Ehm I realised that I did not explain how such a lightweight streaming
interface would look like:
* function accepting a string -> function accepting a Dumpable: either a
QStringView or a void(Sink) function, always behaving like a void(Sink function)
* function returning a string -> void(Sink) function (i.e. QString toString()
-> void dump(Sink))
This makes sense only for functions immediately using the string passed in, but
is lightweight to implement, and allows streaming in the result without
creating temporary QStrings (it also can help when decoding on the fly).
Fawzi
> On 15. Jun 2020, at 01:27, Fawzi Mohamed wrote:
>
> In the past I worked with the tango library with the D language, that did try
> to avoid heap allocations and in my own blip library I had build most of the
> text output on a Sink: a functor that accepts a string.
> For graphical user interfaces that is not an issue still I think that a Sink
> defined as
> ```
> using Sink = std::function(void(QStringView));
> ```
> can give a nice lightweight “text streaming” interface.
> I played a bit with it, but my goal wasn’t developing that part, but I wanted
> to come back and benchmark it to see if my feeling was correct.
>
> I basically benchmarked
> ```
> void writeQString(QTextStream , int repeat = 100) {
>s << QLatin1String("start\n");
>for (int i = 0; i < repeat; ++i) {
>QString base = QStringLiteral(u"bla bla");
>for (int j = 0; j < 3; ++j) {
>s << base.repeated(j);
>s << QStringLiteral(u"%1 bla %2 %3\n").arg(QStringLiteral(u"
> ").repeated(j), base, base + base);
>}
>}
>s << QLatin1String("end\n");
> }
> ```
>
>
> Against a version using a Sink
> ```
> void repeatOut(Sink sink, int nrepeat, std::function dumper) {
>for (int i = 0; i < nrepeat; ++i)
>dumper(sink);
> }
>
> void writeDumper(QTextStream , int repeat = 100) {
>Sink sink = [](QStringView str){ s << str; };
>sink(u"start\n");
>for (int i = 0; i < repeat; ++i) {
>QStringView base = u"bla bla";
>for (int j = 0; j < 3; ++j) {
>repeatOut(sink, j, [base](Sink sink) { sink(base); });
>[base, j](Sink sink) {
>repeatOut(sink, j, [](Sink sink) { sink(u" "); });
>sink(u" bla ");
>sink(base);
>sink(u" ");
>sink(base);
>sink(base);
>sink(u"\n");
>}(sink);
>}
>}
>sink(u"end\n");
> }
> ```
> What I learnt is that
>
> 1) you have to be careful about comparing with String::repeated because
> adding a large string enlarges the cache of the QTextStram and makes
> comparison invalid (QString seems then much faster).
>
> Not having understood point 1 I looked at passing all function objects as
> const & (which was faster), and finally using a non owing functor reference
> (like function_view discussed by Vittorio Romeo in
> https://vittorioromeo.info/index/blog/passing_functions_to_functions.html ),
> which was even faster (in D1 delegates were non owning).
>
> The full source of my benchmark is available at
> https://github.com/fawzi/qtIoTest and on my macBook 2.3 GHz i9 with flash
> storage I got the following numbers:
>
> Debug
> "QStringAlloc" write: "485.847010" writeFlush: "485.879594" ioTime:
> "486.158937" flushFails: 0
> "LambdaAndSink" write: "987.612934" writeFlush: "987.640574" ioTime:
> "987.993028" flushFails: 0
> "LambdaAndSinkCRef" write: "843.016367" writeFlush: "843.030152" ioTime:
> "844.147218" flushFails: 0
> "LambdaAndSinkView" write: "483.614625" writeFlush: "483.630823" ioTime:
> "483.777161" flushFails: 0
>
> Release
> "QStringAlloc" write: "305.894019" writeFlush: "305.924705" ioTime:
> "306.177800" flushFails: 0
> "LambdaAndSink" write: "102.757184" writeFlush: "102.768369" ioTime:
> "102.955962" flushFails: 0
> "LambdaAndSinkCRef" write: "91.224731" writeFlush: "91.232051" ioTime:
> "91.642540" flushFails: 0
> "LambdaAndSinkView" write: "79.895681" writeFlush: "79.915456" ioTime:
> "80.602022" flushFails: 0
>
> In debug mode the function_view Is just as fast, but in release mode it is
> *much* faster, indeed all streaming options win over the plain String
> allocation.
>
> So I have two points in my conclusion:
>
> a) I think that it could make sense, if there is interest, to use Sink and
> void(Sink) functions (or function_view) more, and provide corresponding API
> (one can for example define a Dumpable that can be instantiated with either
> a QStringView of a void(Sink) function, and thus have format(Sink,
> QStringView, Dumpable, Dumpable,…), or even a wrapper around a Sink that
> provides nicer stream like interface.
> Strict GUI programming might not gain much, but any string output would be a
> bit faster, and I think, cleaner.
>
> b) Independently from the text streaming discussion, a non owning function
> pointer like function_view could
