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

Denis Shienkov denis.shienkov at gmail.com
Sat Jul 2 11:26:33 CEST 2016


Hi all.

Then it is necessary to bring up a question of use of C-style of 'arrays',
e.g. there has to be something like:

qt:containers vs std::containers vs C-arrays

Because I see in Qt sources, that often are uses C-arrays, that is "worse"
than qt:containers vs std::containers.

So, then we need do not use C-arrays at all too.. )))

PS: I prefer to use STL if it is justified, so, seems I vote for p.5.

PS2: If you Qt's developer, you should know STL (at least, you should 
read about :) )!

BR,
Denis


01.07.2016 21:36, Thiago Macieira пишет:
> Premises not under discussion:
>
> 	Qt source code is product and meant to be read by our users
> 	Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>      if (d->currentReadChannel >= d->readHeaders.size()
>          || d->readHeaders[d->currentReadChannel].empty()) {
>          Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
> 	empty		->	isEmpty
> 	push_back	->	append
> 	front		-> 	first
> 	pop_front	->	takeFirst
> 	cbegin		->	constBegin
> 	cfind		->	constFind
>




More information about the Development mailing list