Him I'd like to update and conclude this discussion.
After crunching the numbers, we have a 30% download ratio for MSVC2013 (compared to total Win downloads including 5.9.0). That's a very significant amount. Theerfore we cannot drop MSVC2013. At the same time the confirmation was given that 5.11 will no longer support MSVC2013. Once dev has been branched off for Qt 5.10 development, feel free to make use of this decision in the new (5.11) dev branch. -- Alex > -----Original Message----- > From: Development [mailto:development- > [email protected]] On Behalf Of Philippe > Sent: Saturday, 17 June 2017 14:14 > To: [email protected] > Subject: Re: [Development] Let's please drop MSVC 2013 for 5.10 > > > Decision making should weigh pros and cons. The observed pattern is > > however "We see something sub-optimal, therefore we choose the other > > approach, not matter matter what". This is unreasonable. > > I don't see reasonnable the use of the latest Qt technology on one hand > (5.10), > together with an old compiler (VS 2013) that does not even support well the > C++ > standard defined back in 2011. > > This sounds reasonnable that ressources are spent fixing Qt issues rather than > solutions around compiler quirks. > > If some users think otherwise, they can still modify Qt (5.10) to use with > their old > favorite compiler. > > Philippe > > On Sat, 17 Jun 2017 11:14:18 +0200 > André Pönitz <[email protected]> wrote: > > > On Fri, Jun 16, 2017 at 07:09:20PM -0700, Thiago Macieira wrote: > > > On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote: > > > > On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote: > > > > > Here's a tricky question: how do you create a QStringLiteral > > > > > with non-ASCII characters that will work on all our supported > > > > > compilers? > > > > > > > > I don't have to, unless I have profiler supported evidence that it > > > > matters. > > > > > > QStringLiteral is infinitely faster at runtime than QString::fromUtf8. > > > It also occupies roughly 33% less memory than QString::fromUtf8 of a > > > literal, as the latter needs the narrow character equivalent > > > (read-only memory) plus the UTF-16 converted text (heap, which has > > > overhead). > > > > We are talking about a handful strings with non-7-bit chars, mostly in > > tests. > > > > Cycles spend for these cases will never sum up to the order of > > magnitude to one failed CI integration. > > > > > This is for a simple, static message. > > > > > > > In the common case where it does not matter, the string can be > > > > created at run time. > > > > > > At a cost and overhead. > > > > Dwarfed by the costs of the proposed alternative. > > > > > > QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!') > > > > > > > > instead of > > > > > > > > QStringLiteral("Möööp!") > > > > > > Yeah, no thanks. > > > > We are talking about a handful strings with non-7-bit chars, mostly in > > tests. > > > > Worse uglifications have been proposed to Qt proper for even less > > gain. > > > > > The whole point is that we can do better. All we need to do is drop > > > an old, buggy compiler. > > > > That's not 'better', that's a price to pay. > > > > I don't have any stake in MSVC nor in Windows in general, in fact > > given that it's weekend, I do not care at all. > > > > Decision making should weigh pros and cons. The observed pattern is > > however "We see something sub-optimal, therefore we choose the other > > approach, not matter matter what". This is unreasonable. > > > > Andre' > > _______________________________________________ > > Development mailing list > > [email protected] > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
