Well, I for one do not welcome our new std:: overlords. After many years of using C++ (since 98) and diving deeper into it, I think Qt and the C++ committee are two completely separate audiences. I cringe at stl code. I once asked a question on how to reverse something, and what followed was something that used some crazy templating and emplace_back and was completely "unreadable" to the average person. I read it, and it took me a while to deconstruct what it was actually doing. I've resolved to learn more about C++ after that, and the result of my studies so far are that stl people are far more interested in telling the compiler how to build the code than actually accomplishing something. That is not a bad thing, and probably very desirable perspective for the stl committee to have. However, Qt licensees (open and commercial) are not the committee, and are more interested in accomplishing something rather than providing a library. As a result, the code of a Qt-using program should be readable by average developers not big into C++. Meanwhile, it also does not serve anyone to duplicate stl. I do not know where the threshold is for duplication (probably pretty high) but I would encourage the threshold to be low for augmentation.
Qt's motto is "Code less. Create more." which I think reflects the perspective of Qt-using community. That is definitely not the motto of the std committee. (Though at times they do align) One thing I have a huge concern over is the upcoming (if any) integration of std::async, which I thought would have some effects on QFuture et. al., (see the other thread concurrently going on) I would hope that Qt only forces users to use std when there is no possible Qt-value add. I don't want Qt to decline to add a Q* class because they are forcing the use of std. If there is a value-add then I think Qt should provide it. Finally, and least importantly, but still important, Qt classes just look so much prettier, and I think that helps non-C++ developers. (Of which there is an increasing number of al the time) > Sent: Sunday, February 02, 2020 at 6:00 AM > From: "Daniel Teske" <q...@squorn.de> > To: development@qt-project.org > Subject: Re: [Development] The future of smart pointers in Qt API > > > > Pros I can see: > > 1) Qt style > > STL has different naming convention that looks alien to Qt API. It leads to > > inconsistency. > > The "Qt projects not using the standard library" era is over and the > sooner that is understood the better. That inconsistency is just > something to get used too > > Qt does not duplicate: > > std::optional > std::tuple > std::function > ranges > algorithms > parallel algorithms > > All of them are great features that I would expect every Qt project to > have some use for. > > This list will grow in the future because C++ evolution is quite a bit > faster then in the past. This isn't just that the standard gains > features faster, but that compilers implement them immediately and from > my experience these features are adopted in the industry. > > In the future mixing Qt and standard classes will be even more common. > > The important question for Qt is: How to leverage the evolution of > standard C++ for the best combined offering. > > daniel > > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
