[Development] Question about QCoreApplicationData::*_libpaths
kevin.kofler at chello.at
Fri Jan 22 22:51:30 CET 2016
Marc Mutz wrote:
> Judging from the comments on my blog post from 2010(!), when they hear
> QList people first think std::list (ie. linked list). Then they see that
> there's also a QLinkedList and start thinking that QList is something like
> std::deque. And then, if they are lucky, they realise it isn't that,
> either. Because both of those std containers guarantee stability of
> references under appends, as does QList _by default_.
It's funny, because having learned C++ mostly together with Qt, I just see
std::list and std::deque as terse and incomplete names, and so std::list is
what I think is incorrectly named, not QList. :-) Qt would never approve a
name like "deque" in an API review!
Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4
changes by now.
>> Everything else is a blatant API abuse.
> Tell that to the authors of QToolBox and QDataWidgetMapper (off the top of
> my head). Better yet: put code where your mouth is and fix that blatant
> API abuse. I'll be more than happy to give you a +2 on that one.
Oh, there's code inside Qt that sits on references into containers? Ewww!
>> undeprecate QtAlgorithms
> And this is where I stop taking you seriously, sorry. You can demand such
> nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
> algorithms from the STL for Qt. Or play god deciding which are the ones
> "no- one will ever need" or "should never use" - IYHO.
I'd already be happy with those that were (are, actually) already there. I'd
rather have 10-20 common algorithms with a convenient API than 80+ obscure
ones that force me to use iterators (especially the boilerplate .begin() and
.end() iterators that will be used in 99+% of the cases – copy&paste
More information about the Development