> On Jan 23, 2016, at 1:12 AM, Kevin Kofler <[email protected]> wrote: > > Ziller Eike wrote: >>> I would like that trend to continue. The likely next candidates are >>> threads, futures and locks. >> >> +1 > > I wonder why everyone so far agreed on that. So let me dissent: I think > having these things in Qt with Qt-style APIs is a good thing and I don't see > why we should discard our solution for the STL one. At most, where it makes > sense, we could wrap the STL stuff as we're doing with std::atomic.
The +1 statement above doesn’t mean that there is no room for convenience on top of the std features, and integrating them with Qt features like signals/slots. E.g. std::future doesn’t support asynchronous result reporting (some thread has at some point to block for getting the result in the end), or progress reporting, something that the QFutureInterface, QFuture, QFutureWatcher triple provides. (Though, also only partially in Qt. We added more within Qt Creator, which was supposed to migrate to Qt but didn’t make it.) That still means that any Qt solution to that should best only be convenience around std::future and std::thread and the async algorithms that will probably come to C++ at some point. We will want to not block ourselves from coming C++ features like future.then(...) and so on. > I find it much nicer and more readable if I can just write sort(v). > > +1! > > And I don't think ranges are the answer here. It's just another layer of > overengineered abstraction (as they will surely be implemented as a pair of > iterators in practice) when in 99+% of the cases you just want to operate on > the whole container anyway. > >> Or "const List foos = transformed(myThings, &Thing::foo);" >> instead of "List foos; std::transform(myThings.begin(), myThings.end(), >> std::back_inserter(foos), std::mem_fn(&Thing::foo));” (notice that “foos” >> is also not const in the “pure" std version) > > Wow, the STL version is horrible! std::back_inserter is particularly ugly, > and the usual misleading STL name (which suggests "backwards", when actually > it means "to the back", so when inserting multiple elements, forward) does > not help either. > >> We started some experiments with convenience wrappers for std algorithms >> for use in Qt Creator when we started requiring C++11: >> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h > > Interesting. That could be a starting point for a QtAlgorithms successor. > >>> why do they use C++ if they so hate it? >> >> Maybe they don’t hate it, but still wished it had a less verbose API if >> you don’t need the verbosity. > > The funny thing is that only redundant boilerplate is verbose in the STL. > The stuff that matters, the API names, are horribly terse (e.g. "deque"). > > And I don't hate the C++ language, only its standard library. The language > is actually great, much better than Java or Python. So, since Qt lets me not > touch the STL with a 10-foot pole, I see no problem with using C++. (Qt is > also by far the best class library out there.) > > Kevin Kofler > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
