On Wednesday 20 January 2016 16:03:17 André Somers wrote: > Op 20/01/2016 om 15:48 schreef Ziller Eike: > >> On Jan 20, 2016, at 3:12 PM, Marc Mutz <[email protected]> wrote: > >> > >> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: > >>> I think it would be productive for the discussion to build story of > >>> what we want to do. A story of the big picture. Maybe as a first step > >>> we can show how we tackle problems with Qt 5 and what are the proposed > >>> technologies in the future C++ standard. > >> > >> For me, Qt always was "the C++ standard library that C++ lacked". Ever > >> since Qt 3, it also integrated pretty well with the rest of the > >> standard library. That was easy, because pretty much the only thing > >> that the standard library had and Qt didn't were the algorithms, and Qt > >> and the STL algorithms integrated well. And there were conversion > >> functions for pretty much everything to/from std. > >> > >> We even deprecated our algorithms when we started requiring full C++98 > >> support in 5.0. > >> > >> We used to roll our own atomics, but dropped them in 5.7 when we > >> required partial C++11 support. We rolled our own foreach, and now it > >> looks like we're dropping it in favour of range-for. > >> > >> I would like that trend to continue. The likely next candidates are > >> threads, futures and locks. > > > > +1 > > > >> Now that C++ punches out a new standard every three years, I would > >> change that into "Qt is the part of the C++ standard library that C++ > >> sill lacks". I would like Qt to continue to integrate well with the > >> standard library and phase out its own solutions as the standard > >> library catches up. > >> > >> We have been doing that in the past. It's just as C++ standardisation > >> accelerates, so will the need to phase out Qt features that got > >> superseded. > >> > >> I perceive, however, that for many people, Qt is what makes them forget > >> they're working on C++, a language they would not otherwise poke at with > >> a long stick. They probably also cannot tolerate writing > >> std::sort(v.begin(), v.end()) instead of qSort(v). > > > > I find it much nicer and more readable if I can just write sort(v). > > > > 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) > > > > 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/alg > > orithm.h > > Nice, thanks for the link. > > At a previous job, I ended up defining a macro called all (and a > constAll) that just expanded to begin(v), end(v). That already helped in > how verbose the calls to algorithms looked. > > std::sort(all(v)) > > vs > > std::sort(begin(v), end(v)); > > Sure, a macro is ugly, but it did the trick. When you need more control, > you can specify begin and end explicitly, of course. > > >> But Qt is available in D and Python, too, so ... > >> > >> 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. > > Indeed. After watching some courses by Stephanov, I actually learned to > appreciate it. But I stil dislike the API in many places. C++11 makes > much of the std easier to digest though.
Then now is the time to chime in on the C++ ranges proposal and voice your opinion(s). "Let him speak now or forever hold his peace" :) -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
