I think we all agree with the goal we have with Qt to make C++ development accessible and easy. This is something we will continue to do.
But the question asked here was about how we use a certain c++11 feature in our *implementation*. This is clearly different from what we do with our APIs and what we ask our users to know. To implement Qt, we can and should use C++ in the most efficient way. If it makes sense to use certain features (and we can actually use them on all platforms), let's use them. But of course let's not force all of these upon our users. Cheers, Lars On 04/12/15 08:58, "Development on behalf of Smith Martin" <development-boun...@qt-project.org on behalf of martin.sm...@theqtcompany.com> wrote: >+1 > >martin > >________________________________________ >From: Development <development-boun...@qt-project.org> on behalf of Randall >O'Reilly <randy.orei...@colorado.edu> >Sent: Friday, December 04, 2015 8:35 AM >To: Marc Mutz >Cc: development@qt-project.org >Subject: Re: [Development] RFC: more liberal 'auto' rules? > >This debate between the std:: lib and wider C++ community vs. the Qt >traditions seems never-ending :) At the risk of perpetuating the inevitable >flame war, my perspective is well captured in this article: >http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ > >C++ is WAY too complex of a language, and other alternatives are rapidly >gaining users (particularly Python in the domain of scientific computing). >The STL and its sea of recursive templates has in particular been incredibly >daunting. C++11 helps, but the complexity remains.. > >Of course, there is no “right” answer in any of these language debates: only >different people optimizing different ends of many different fundamental >tradeoffs. > >C and C++ in general tend to attract people who favor optimization over >simplicity / usability of the language. Marc is clearly in that camp, >advocating many ways of optimizing performance.. With all the new language >options, presumably those that stick with C++ are even more apt to be obsessed >with performance.. > >But Qt is beloved by many (myself included) because it provides a *simple*, >elegant, well-designed, well-named API, that does a lot of stuff.. Not >because of its optimal performance or cutting-edge language features and >adherence to the C++ standard.. > >I got “stuck” in C++ for historical reasons: it was the only viable option for >object-oriented programming in the 1990’s. Sure, I care about optimization >for my critical inner loops. But for everything else, I really wish it was a >lot simpler. And again, I value Qt for making it so in the GUI, which >consumes a huge amount of my code, and has minimal performance demands, >because it is a GUI and the human in the loop is almost always the rate >limiting factor. Of course we don’t want exponential slowdowns with large >numbers of Widgets etc, but I’ve never found that to be a problem in Qt. > >So anyway, this is just a vote to keep with the solid tradition of favoring >simplicity, clarity, usability, readability, etc, instead of just following >the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite >everything in Go or Python or something.. :) > >- Randy > >> On Dec 4, 2015, at 12:49 AM, Marc Mutz <marc.m...@kdab.com> wrote: >> >> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>>> That depends on how big the remainder is. I argue that we're relevant >>>> enough that our own direction is big enough to be of relevance. >>> >>> That didn't come out right. Rephrasing: >>> >>> Qt has enough market share by itself that we can choose our own direction >>> and still be relevant. We are allowed to disagree with what others do. >> >> Yes, but only if we know *better*. >> >> I very much doubt that more than very few people in Qt development have the >> knowledge to objectively overrule the accepted C++ authorities. I myself have >> seen over and over again that how I thought a feature should be used was >> blown >> to smithereens by members of the committee, usually rightfully so. >> >> So the default should be to follow what the greater C++ community is doing, >> while *divergence* from that needs to be argued for. >> >> Everything else is approaching hubris, imo. >> >>> we don't use exceptions >> >> ...and look at the sorry state of error handling in Qt - every class does it >> differently... It's ok not to use exceptions, but not having a consistent >> error >> handling strategy doesn't put us into a position to throw that stone. >> >>> we don't use underscores >> >> ... except we do (grep "qt_"). And there's *nothing* wrong with that! >> >> Thanks, >> Marc >> >> -- >> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt Experts >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
