On Sat, Nov 11, 2017 at 10:27 AM, Richard Duivenvoorde <[email protected]> wrote:
> On 11-11-17 01:03, Nyall Dawson wrote: > > The "TLDW" for interested parties: > > - Qt containers (qlist, qvector, qmap, etc) are unmaintained, They > > won't be removed by upstream, but you shouldn't use them if you have a > > choice > > - QList is absolute rubbish and should never be used, unless you're > > forced to by Qt API. It's likely to be killed in Qt 6 (becoming just > > an alias for QVector) > Here are my (very subjective) reasons for choosing one or the other approach WHY USING MAINLY/ONLY QT API - Qt API is well documented with examples on http://doc.qt.io/qt-5/ and using a single API instead of a mix it's a clear advantage (you don't have to constantly ask yourself which API you need to use in a particular call) - Qt API is simple and intuitive - Qt API is more readable (camel case, no std:: etc.) - Qt Containers are simple to use and cheap to copy (with caveats) - QString has no real alternative for UTF8 WHY USING MAINLY/ONLY STL API - Qt Containers are not for-range loop friendly (detach issues) - Qt Containers are kind of deprecated - STL is part of a standard, may lower barriers to entry for not-Qt devs CONCLUSIONS - I feel that the real motivation is to stay away from Qt containers, if it wasn't for them we would not probably be here discussing in the first place - I'd try as much as possible to avoid mixing two APIs: if we go for STL, let's try to minimize Qt API usage or constraint it to certain domains (for example: QStrings manipulation, dispatcher, GUI) - no strong opinions here, but the greatest danger is to not decide: we'll end up with a mixture of APIs and styles and code reviews will become completely arbitrary, with people asked to switch API depending on who reviews the code (and when the review is made) - whatever we agree upon, it *must* be documented clearly in coding guidelines WHAT TO DO? We have a few strong C++ coders in this community, I think that the best way to proceed would be to let them articulate the different options that we have and - if the don't agree - let the core devs vote on the proposals they come out with. Btw, thanks for binging up this discussion! Cheers. -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
