[Development] RFC: more liberal 'auto' rules?

Bubke Marco Marco.Bubke at theqtcompany.com
Fri Dec 4 16:46:58 CET 2015

On December 4, 2015 08:35:19 Randall O'Reilly <randy.oreilly at Colorado.EDU> wrote:

> 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..

Hmm,  do you really believe we cannot improve? If you compare signal and slots with resumable functions it looks quite complicated for many use cases. Look how complicated our network API is. It could be much easier with resumable functions. I don't say signal slots should go away but should be used in places their they have still an advantage. 

Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but now C++ is incorporating many advanced features for concurrency and other areas from C#,  Python and other interesting languages. The world is changing and we should adapt to this changing context. 

> 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.mutz at 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.mutz at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 

More information about the Development mailing list