On 09/06/2019 00:09, Kevin Kofler wrote:
André Pönitz wrote:I see that pattern, too. But now, instead putting the break between 3) and 4), the whole thing is killed, and everybody downstream has to do 1)-3) again, or put up with what the standard offers.And could prevent overextension by -x'ing the respective change on gerrit. So *that* sounds fixable.But why should Qt let itself be crippled by the STL's limitations? Qt classes being better than STL classes is a GOOD thing.
Perhaps you forgot to read the part where I said:
Then, it comes a moment when "upstream" stuff has more and more advantages -- more speed (algorithms), more flexibility (e.g. mutex classes and utilities; shared_ptr<T[]>; etc.), more static analysis tooling, and so on, than the equivalent classes offered in Qt.
So now it's a good time to re-read it.
* We could keep things where they are, supported, thus offering the easier APIs; but simply reimplement them on top of the "upstream" equivalents. (Ignore the possible ABI break.)The last one is the most reasonable.It is not, because it means Qt can no longer offer features that make it better than the STL. Instead, the Qt implementation should be kept as is.
Perhaps you forgot to read the part where I said:
Then, it comes a moment when "upstream" stuff has more and more advantages -- more speed (algorithms), more flexibility (e.g. mutex classes and utilities; shared_ptr<T[]>; etc.), more static analysis tooling, and so on, than the equivalent classes offered in Qt.
So now it's a good time to re-read it.
Long story short, making qSort() call std::sort() might not have kept the behaviour contract with the user.*shrug* And what if I, as a user, would not care? What about https://valdyas.org/fading/hacking/happy-porting/If you break the contract with the user by silently changing the underlying implementation incompatibly, you also force the user to do porting (e.g., from qLess to std::less). So the user will care. QtAlgorithms should just be undeprecated. I don't care whether std::sort is faster. If the version of Qt I tested with was fast enough, then I'm perfectly fine with newer versions not being faster, no matter how fast some incompatible implementation elsewhere is (and I don't care whether it happens to ship with my compiler or not).
I deflect your straw man attack using my amulet of logical fallacies, roll 3d4, and summon ad-hominem: this is the kind of reasoning of those people asking Henry Ford for faster horses.
A VERY NOT AMUSED, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
