Hi, On 08/06/2019 19:17, Boudewijn Rempt via Development wrote:
I kept out of this for the longest time, especially because people have been quoting my blog post, but I give up now.On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote: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.Qt's problem has been that it was started as "let's make c++ accessible to "java coding drones".
Please don't say "coding drones".
So it wasn't a serious C++ library,
[citation needed]
so nobody using Qt cared about C++ (I still don't care about C++, I don't do C++ because it's awesome, but because I inherited a codebase that uses it),
I still consider C++ a _tool_ and not necessarily an _end_. Surely that's also what lots of our customers see out of it.
and everyone doing "proper" C++ looked down on those undereducated morons who were using Qt, instead of "proper" C++.
Do not use this language. (And, [citation needed]).
And then Qt became one of the most-used C++ platforms. Mostly because Windows developers were even more often hit by the fire-and-motion tactics of Microsoft, and because of the web and other languages getting useful and all of that. So now C++ people have noticed Qt, and Qt people have noticed the C++ people, and the reaction is... Let's do more of the stupid stuff that's been in STL.
Let's write documentation that's only accessible to CS majors, no, let's do better, let's have documentation only accessible to CS professors!
[citation needed]
There is NO useful documentation for STL.
Is this a comprehensive review of ALL the information ever published about the Standard Library?
Just look at how ivory-tower the documentation for std::unique_pointer is on cppreference. Good documentation tells me "what does this, why should I care, when should I use it, how should I use it". The cppreference documentation tells me "this is the right vocubulary to talk about this topic, and there are these weird cornercases".
Straw man. cppreference is to be an API reference for experts, not a tutorial. From their FAQs:
The primary objective is to have a good specification of C and C++.
Tutorials about smart pointers are elsewhere.
In other words, the advantages of keeping the Qt equivalents start to be (seriously) questioned. We're therefore left with the question of what to do with these equivalents.Like always, like I'm always being told, but dammit, we're trying to do that, only we're not getting through gerrit, much, you should have upstreamed it. The stl should have become Qt-like, not Qt stl-like.
I cannot parse the first sentence at all.
* We could play the catch-up game, but that requires a development investment that is simply not there any more, and is even questionable (is it the job of people developing Qt to rewrite algorithms widely available elsewhere?).Qt never had the manpower to maintain its stuff, not even in the Nokia days.
So?
* We could just deprecate and tell people to migrate away. That's kind of the whole point of this thread, and comes with all the annoyances, and people reimplementing them downstream because they still want the convenience of a qSort(vector) over std::sort(vector.begin(), vector.end()).It's not about annoyances. It's about not having to rewrite code, spend time, without getting any tangible benefit in the hands of my users. The kind of memory savings Marc Mutz keeps hammering on about are totally, utterly, completely, devastatingly irrelevant for me. Qt churn doesn't get me any new users, or makes any of my current users happier than they were already.
I reject this claim. It's completely short sighted. In this design, any sort of internal maintenance one does on a piece of software does not bring "tangible benefits" to the users.
If you write a library, you only have one task: make sure your users can deliver functionality to their users faster, better, more reliably than if they would use another library. Making your users spend time porting, is wasting your users time and money.
No. There is, for instance, also the task of maintaining said library. My 2 c, -- 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
