>>And, c'mon, std::optional's API is just not going to be topped by QOptional.
I don't know the QOptional plans (or no-plan), but as today, on the Mac, the latest XCode 9.1 still does not provide std::optional. With Qt, at least, when something is available, it is available in all platforms, and Qt users can count on that. >>Where I come from, we see customer's code "out there", and they almost never >>use Qt in isolation. >> They have to interface with some 2rd-party library which, naturally, does >> _not_ use Qt types, but std ones, >> and developers on those projects need to interact with both. >> They also surprisingly often know about and use Boost. >> Not only do they need to learn two different APIs (append() vs. push_back()), >> they also face the impedance mismatch between Qt and every other C++ library >> on the planet. I also see that, except that boost dependency is often rejected. But I also hear praises about Qt documentation and ease of learning. I like your expression "impedance mismatch", but don't see this as a problem in practise. I mean, when a std:: container needs to be used for an interface with another library, then let's use is. No big deal. Philippe On Sat, 02 Dec 2017 17:48:19 +0100 Marc Mutz <marc.m...@kdab.com> wrote: > On 2017-12-01 23:12, Philippe wrote: > >>> it's existential for Qt to get off its own container classes. > >>> I shall in the future extend that statement to anything that overlaps > >>> with std. > > > > Two points to keep in mind: > > > > 1) the std implementation varies with compiler vendors, each one with a > > different set of bugs, unit tests and sometimes performance. While with > > Qt, the implementation is more uniform. This to say, I feel more secure > > using Qt implementations for an application that runs on multiple > > platforms. And cross-platform is the core business of Qt... > > You make it sound as if std implementations are much more buggy than Qt's. I > don't even know how to respond. I'm sure STL, Marshal Clow, Howard Hinnant, > and all the others std library implementers will be pleased with your > analysis. > > Have you tried using QVector with a type that has no default constructor? > Using that nice API forces users to supply an unnatural operation on their > types (if they control the types in the first place). > > As I said multiple times before: my arguments would be pretty weak if Qt's > implementation quality matched or exceeded the quality of the corresponding > feature in the standard library (and that's why we have QStringView, > incomplete as it still is, because of QString), but except for QString, and > QFuture, which, however, lacks the QPromise counterpart, I don't see any > other cases. > > > 2) a majority of Qt users are not C++ wizards, and ease of use / > > intuitive api, is of primary importance... std does not always shine > > here. > > If that analyis were true, you'd need to explain why it is, then, that the Qt > containers now have more or less the same API as std ones, when in Qt 1 they > were very different. And why I keep needing to fight off QOptional. These are > ideas that do not come from Qt. They come from C++/Boost. Qt is "stealing" > them, wrapping them up in a camelCase interface, omitting the hard parts of > the implementation, adding some optimisation for Qt types, and then stand > here as Thiago does and say that the Qt type needs to stay because of that > optimisation. Even new-style Qt 5 signal/slot connections were available in > this form in Boost since at least 1.32, ie. something like 2004. In Qt 3 > times, people would have protected loudly over the need to write ugly code > like &QLineEdit::returnPressed instead of SIGNAL(returnPressed()), but lo and > behold, there's been no public outcry. Qt silently adopted the interface that > was inspired by it's own invention, but had since succeeded in keeping up w ith the rest of the world (Boost.Signals). That's a _good_ change. It helps people integrate their code with Qt. because integrate they must. > > Where I come from, we see customer's code "out there", and they almost never > use Qt in isolation. They have to interface with some 2rd-party library > which, naturally, does _not_ use Qt types, but std ones, and developers on > those projects need to interact with both. They also surprisingly often know > about and use Boost. Not only do they need to learn two different APIs > (append() vs. push_back()), they also face the impedance mismatch between Qt > and every other C++ library on the planet. > > Developers just can't cocoon inside the Qt world. They need to interact with > the real world, and Qt actively prevents that with its copies of upstream > APIs all over the place, and it's antiquated (read: pre-C++11) programming > model. > > Two things have happened since 2010: C++ is progressing fast again, as a > language, and, more importantly, the _tooling_ situation has dramatically > improved. In a world where your static analysis tools actively warn you about > common Qt idioms (mutexes, but also naked new all over the place, in > violation of CoreGuidelines), Qt's insistence on providing it's own copies of > std functionality force users to choose between Qt-ish APIs or static > analysis coverage. A developer that chooses a nicer API if there's another > cross-platform alternative which is functionally at least on par, but better > integrated with his tools (IDE, compiler, clang-tidy, ...) should have a long > meeting with his manager. > > But Qt is just maintaining it's own NIH/our-APIs-are-superior stance. As > evidenced by this thread. But it's users will move on. Personally, I'm doing > more Modern C++ trainings than Qt trainings these days. That has to do with > me not knowing QML much, but _also_ with a surge of interest in C++. > > And, c'mon, std::optional's API is just not going to be topped by QOptional. > What should they do? snake_case vs. camelCase? That's what we need to invest > several man-days of development work in, to rename the functions and stick a > Q in front of the class name? > > Thanks, > Marc _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
