[Development] Use of Standard Library containers in Qt source code

Rafael Roquetto rafael.roquetto at kdab.com
Fri Jul 1 23:31:17 CEST 2016

On Fri, Jul 01, 2016 at 01:05:45PM -0700, Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:52:24 PDT Konstantin Tokarev wrote:
> > > I had to look up the definition of readHeaders in the review and note that
> > > it was a std::deque, not a Qt container.
> > 
> > STL was standardized 18 years ago, I think it should be enough to get used
> > to empty().
> Qt API conventions predate the Standard Library standardisation. Qt's style 
> exists because -- quite by definition -- Qt developers think their style is 
> better. Moreover, Qt is recognised for having a nice, easy-to-learn API, 
> whereas the C++ Standard Library meets quite often the exact opposite reaction 
> (yes, anecdotal evidence).

I second this. Qt API is highly praised, for a good reason. It is one of the
big assets of Qt. IMHO the compromise of subclassing STL stuff inside the
QtStl namespace seems like a good deal - it may require some effort, but we
get to keep a clean API. I would even go as far as saying this is better than
simply allowing unrestricted STL code into Qt source code, because unless we
rename (ruin) some method signatures in the Qt API, we would end up with the sort
of inconsistent source code demonstrated by Thiago's example, which I judge to
be the worst-case scenario.

Of course, all this assumes the introduction of a QtStl namespace to be a
feasible task. Whether it really is I cannot say.

Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3599 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160701/ab04145c/attachment.bin>

More information about the Development mailing list