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

[Jake Petroules]

I always find it hilarious how people start debates about UTF-8 vs UTF-16 in 
string APIs. Let us not forget that in an ideal world, the QString API wouldn't 
expose the underlying encoding *at all*, and it would be an implementation 
detail unknown to users.

See Swift's String class for example: 
https://developer.apple.com/swift/blog/?id=30

If you're thinking in terms of code units instead of in terms of grapheme 
clusters, you don't truly understand Unicode. And also end up with historical 
radioactive waste like UTF-16.

On Jul 12, 2016, at 5:58 AM, charleyb123 . 
mailto:charleyb...@gmail.com>> wrote:

On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke 
mailto:marco.bu...@qt.io>> wrote:

, Lets face it, the world is much bigger than Qt, and I think there is 
much to gain if we integrate better with alien libraries.

My understanding is that most alien libraries are not binary-based (i.e., they 
are ternary or use other forms of multi-valued-logic (MVL)).

;-))

--charley

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[charleyb123 .]

On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke  wrote:

> , Lets face it, the world is much bigger than Qt, and I think there
> is much to gain if we integrate better with alien libraries.
>
My understanding is that most alien libraries are not binary-based (i.e.,
they are ternary or use other forms of multi-valued-logic (MVL)).

;-))

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

> Why would we want UTF-8? There's no native type for it, unlike UTF-16's
> char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
> ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
> guaranteed to be UTF-32).


UTF-8 is used by many libraries and converting between UTF-16 and UTF-8 makes 
things not faster or better. If you work with text which is annotated with 
ASCII, which is quite common today, the advantages of Utf8 looks quite 
compelling.


But without changing QString to UTF-8 our UTF-8 support could be much better . 
For example we convert mostly to a QByteArray which has to be copied again 
because we have move the ownership of that string to API which is not 
supporting QByteArray. In that case it would be already nice that you would 
have something like QByteArray::takeData(). And this is only one case. Lets 
face it, the world is much bigger than Qt, and I think there is much to gain if 
we integrate better with alien libraries. Actually as I used Qt in the nineties 
it was my impression that Qt had that mindset but than it changed gradually.


From: Development  on 
behalf of Thiago Macieira 
Sent: Tuesday, July 12, 2016 7:33:16 AM
To: development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code

On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
> <https://github.com/boostcon/cppnow_presentations_2016/blob/master/00_tuesda
> y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:

Criticism:
* Qt's dependency on qmake: that's only for building Qt itself, not for your
application. Otherwise, we could always criticise any library for choosing to
use buildsystem X instead of Y.

* Remove moc: why? Moc has a very important use besides signals, that being of
reflection of C++. Until at least C++ 2020, but most likely WAY further,
there's no replacement for that. Therefore, removing moc is removing important
functionality. Let's see CS implement QtScript, QtDBus and QtQml without
moc...

* Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't
implement it properly.

* Signal / slot delivery as a separate library: interesting, I'll give CS
that, but not sure what the value of this is.

* Containers: leveraging STL only makes sense if we drop implicit sharing.
There are many arguments in favour and against doing that, which I will not
get into. What I will say: doing implicit-sharing with STL is the worst of
both worlds.

* Use C++ native pointers: granted, that's also the reason why we're not
reimplementing std::unique_ptr or extending QScopedPointer to have move
semantics.

* Refactor QString: huh?

> What would QString refactor would bring? UTF-8? QStringView?

Why would we want UTF-8? There's no native type for it, unlike UTF-16's
char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
guaranteed to be UTF-32).

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
>  y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:

Criticism:
* Qt's dependency on qmake: that's only for building Qt itself, not for your 
application. Otherwise, we could always criticise any library for choosing to 
use buildsystem X instead of Y.

* Remove moc: why? Moc has a very important use besides signals, that being of 
reflection of C++. Until at least C++ 2020, but most likely WAY further, 
there's no replacement for that. Therefore, removing moc is removing important 
functionality. Let's see CS implement QtScript, QtDBus and QtQml without 
moc...

* Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't 
implement it properly.

* Signal / slot delivery as a separate library: interesting, I'll give CS 
that, but not sure what the value of this is.

* Containers: leveraging STL only makes sense if we drop implicit sharing. 
There are many arguments in favour and against doing that, which I will not 
get into. What I will say: doing implicit-sharing with STL is the worst of 
both worlds.

* Use C++ native pointers: granted, that's also the reason why we're not 
reimplementing std::unique_ptr or extending QScopedPointer to have move 
semantics.

* Refactor QString: huh?

> What would QString refactor would bring? UTF-8? QStringView?

Why would we want UTF-8? There's no native type for it, unlike UTF-16's 
char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java, 
ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor 
guaranteed to be UTF-32).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Cristian Adam]

On Thu, Jul 7, 2016 at 12:06 PM, Marco Bubke  wrote:

> I think it simply a question of time to get used to the STL. You get used
> to many things.
>
> I think we should mind about the new features of C++ which are coming,
> which cannot integrated very well with Qt because we use a different idiom.
>
> I really think we should make it easier for the developer but if we
> provide no way to go the fast path do we really make it easier?
>
> If the context is changing over time, is it not smart to reevaluate
> decision again and maybe go a different route? I don't mean to do it all
> the time but maybe there is a middle path between different
> "fundamentalisms". [image: 😉]
>
Luckily there's Copper Spice, and it seems they want to be the more
*modern* C++ Qt library.

Their latest presentation

has
at page 6 this:

[image: Inline image 1]

The STL containers part is not yet done. Will they keep the move semantics
for the upcoming
containers?

What would QString refactor would bring? UTF-8? QStringView?

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quinta-feira, 7 de julho de 2016 09:10:50 PDT Marc Mutz wrote:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
> > In case we're not getting the deserved attention due to Summer vacations,
> > I'll  post again in a month or so to see if there's any change.
> 
> We have The Chief on record saying that we should use whatever is most
> efficient internally  (https://codereview.qt-project.org/114327 comment
> from 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

He hasn't chimed in on this discussion, which makes me wonder if he's out for 
vacations.

> So from my pov, the only question is whether we stay with Option 4 or relax
> to Option 5, and I'm fine with either.

For me, it's whether we stay with 4 or write the classes from Option 3.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marco Bubke]

I think it simply a question of time to get used to the STL. You get used to 
many things.


I think we should mind about the new features of C++ which are coming, which 
cannot integrated very well with Qt because we use a different idiom.


I really think we should make it easier for the developer but if we provide no 
way to go the fast path do we really make it easier?


If the context is changing over time, is it not smart to reevaluate decision 
again and maybe go a different route? I don't mean to do it all the time but 
maybe there is a middle path between different "fundamentalisms". [😉]


From: Development  on 
behalf of Martin Smith 
Sent: Thursday, July 7, 2016 9:25:18 AM
To: André Somers; development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the ease 
of use of the Qt collections with the efficiency of STL algorithms.


martin


From: Development  on 
behalf of André Somers 
Sent: Thursday, July 7, 2016 9:20:10 AM
To: development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most 
> efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Thursday 07 July 2016 09:25:18 Martin Smith wrote:
> How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the
> ease of use of the Qt collections with the efficiency of STL algorithms.

Yes, for Qt 6, a template that takes an STL API and provides the Qt methods on 
it is something I'd welcome. But not to be required in internal 
implementation, as is implied in this thread. Game devs on CppCon report that 
compilers have problems fully inlining STL container use where it should be 
fully inlined (I myself ran into such a case: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621)

We use STL containers because they are more friendly to the compiler[1], which 
equates to faster and/or smaller, adding more stuff on top will make them 
slower, unless we fiddle with compiler-specific settings such as inlining 
depths, if that helps at all (it didn't for the bug report linked above).

Thanks,
Marc

[1] I don't think everyone here knows that every asm volatile as part of a 
QAtomic operation makes the compiler forget everything it knows about memory / 
value propagation, ie. it writes back registers to memory before and needs to 
re-load values from memory after the asm volatile. It gets better if QAtomic 
is backed by std::atomic, but even on x86, those ops aren't cheap. A cmpxchg 
takes more than 200 cycles to complete, if the memory is off-socket, compared 
to ≤ 0.5 cycles for a reg-reg operation. That's only the case if the object is 
actually shared among processors, but it shows just how bad it can be. On-die, 
it's still something like 20 cycles.


-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

On Thu, Jul 7, 2016 at 9:25 AM, Martin Smith  wrote:
>
> How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the
> ease of use of the Qt collections with the efficiency of STL algorithms.

If anything, why would it need to wait for Qt 6?

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Martin Smith]

How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the ease 
of use of the Qt collections with the efficiency of STL algorithms.


martin


From: Development  on 
behalf of André Somers 
Sent: Thursday, July 7, 2016 9:20:10 AM
To: development@qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most 
> efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Somers]

Op 07/07/2016 om 09:10 schreef Marc Mutz:

On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:

In case we're not getting the deserved attention due to Summer vacations,
I'll  post again in a month or so to see if there's any change.

We have The Chief on record saying that we should use whatever is most efficient
internally  (https://codereview.qt-project.org/114327 comment from
2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

So from my pov, the only question is whether we stay with Option 4 or relax to
Option 5, and I'm fine with either.


I don't think that rules out option 3 either, does it?

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
> In case we're not getting the deserved attention due to Summer vacations,
> I'll  post again in a month or so to see if there's any change.

We have The Chief on record saying that we should use whatever is most 
efficient 
internally  (https://codereview.qt-project.org/114327 comment from 
2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

So from my pov, the only question is whether we stay with Option 4 or relax to 
Option 5, and I'm fine with either.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sexta-feira, 1 de julho de 2016 12:34:15 PDT Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
> > 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
> 
> Of course, Option 4:
> Continue to allow Standard Library containers in internal code (no API or
> ABI constraining) where there's a clear gain in performance and/or size.
> 
> Option 5:
> Allow Standard Library containers in internal code even if performance or
> code size gains are not appreciable or have not been measured.

Concluding this thread:

The opinions are pretty much evenly split among the respondents, so for now 
we'll remain at status quo (Option 4).

In case we're not getting the deserved attention due to Summer vacations, I'll 
post again in a month or so to see if there's any change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quarta-feira, 6 de julho de 2016 11:08:22 PDT Marc Mutz wrote:
> The underlying theme here, I think, is: idiomatic code. Qt has its set of 
> idioms (like ending QObject subclass ctors in QObject *parent=nullptr), but
> it  largely ignores C++ idioms. And that leads to complicated code and
> throws off contributors that are used to idiomatic C++.
[cut]
> C++ is the language Qt is written in. You need to learn the language's
> idioms.

I dispute calling them "C++ idioms". Can you prove that all other major C++ 
libraries except Qt use them? For example, Google code, Folly, etc. Do they 
all use those idioms? Are their developers familiar with it?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Sunday 03 July 2016 12:04:14 Stephen Kelly wrote:
> It is not possible to reason about code like that. I have the feeling that 
> faced with code like that, people just don't attempt to reason about it 
> while at the same time trying to get on with what they are trying to do.

The underlying theme here, I think, is: idiomatic code. Qt has its set of 
idioms (like ending QObject subclass ctors in QObject *parent=nullptr), but it 
largely ignores C++ idioms. And that leads to complicated code and throws off 
contributors that are used to idiomatic C++.

Take this example:

https://codereview.qt-project.org/159693

The copy-swap idiom is two decades old (at least as old as Effective C++ 
ed. 1), but the only uses in Qt are those that I introduced myself. Following 
the idiom trivialises the implementation of both copy and move assignment 
operators. Not following it leads to bugs such as the one linked above.

Using algorithms is idiomatic. too: erase-remove is an idiom, also nearing two 
decades old. It reduces bugs, and helps grok the code for those that know the 
idioms, but, like in any other language, if you don't know the idioms, you 
don't really understand the language.

C++ is the language Qt is written in. You need to learn the language's idioms.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 4 de julho de 2016 13:54:45 PDT Matthew Woehlke wrote:
> Consider... if I ask you what relation the letter 'A' has to the
> alphabet, is it the letter *at the front*, or is it the *first* letter?
> I bet you, and most (native, certainly) English speakers said it's the
> *first* letter. STL's word choices are... a bit like writing code in
> King James' English.

Hence "push" and "pop" for a stack, "front" and "back" for queues, but not the 
2x2 combination of those on a random-access container...

 > I do however feel that Qt's consistent use of verbs for actions and
> non-verbs for properties (i.e. empty vs. isEmpty/is_empty) is far superior.

Not just verbs for actions, that's verbs in the imperative. We also use verbs, 
but in the past participle, for signals ("changed", "happened", "written", 
except where the English language falls short, like "read / read / read" - 
that's why "readyRead" instead of "bytesRead").

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 4 de julho de 2016 13:26:13 PDT Matthew Woehlke wrote:
> Option N+1: Convince the committee to adopt Qt's naming conventions and
> convenience API's in STL2¹ ;-).
> 
> (¹ Or whatever it's being called...)

We can try, but that is orthogonal to the discussion. Such a standard does not 
exist and will not be usable until at least 2025.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 4 de julho de 2016 09:59:44 PDT Christian Kandeler wrote:
> > 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 must admit I don't see a problem here. We are not talking about some 
> random third-party library that people are pulling in gratuitously, but 
> about the Standard Library, an integral part of C++ that every developer 
> should be at least generally familiar with.

Of course, I was able to reason what it was after looking up the definition of 
the variable in question. It didn't cost me more than 60 seconds to do this, 
between the wondering "wtf is he doing", forming a hypothesis, proving it, 
then navigating back and then restoring my frame of mind.

The problem is that I do more than one review a day. I would be surprised if 
there are more than 5 people who do more reviews than I do. And I spend less 
than 10% of my week on Qt, so it's important for me and for those whose 
changes I review that I be efficient.

In this particular case, the fact of using a QVector of std::deques completely 
threw me off and I didn't understand the author's intention at all. I had to 
stop the review, which led to this email.

> Having said that, I personally follow the "use Qt types by default" 
> approach, but should we really regard STL containers as dangerous 
> intruders that need to be kept out if at all possible?

No, I agree we should allow them when there's a clear benefit. Qt has no 
equivalent for std::deque and I do think our time is best spent in other 
things than reimplementing one. That is the status quo and Option 4 in my 
list.

But I am thinking of Option 3: use the Standard Library containers (cake) and 
still have our API (eat it too).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2016-07-02 02:42, Marc Mutz wrote:
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It 
> just happens to be largely consistent with itself instead of with Qt. But 
> camelCase is not intrinsically "better" than underscored_names, and I also 
> fail to see why first() should be intrinsically superior to front().

TBH, this is the fault of the English language :-). The words that Qt
uses for its API are more intuitive to English speakers, if less
consistent. The words STL uses are more logical¹ and consistent, but
less intuitive.

I've never actually stopped to think about STL being logical¹; every
time I use it, it drives me nuts because the API is not "natural".

(¹ In the sense of "strictly conforming to formal logic".)

Consider... if I ask you what relation the letter 'A' has to the
alphabet, is it the letter *at the front*, or is it the *first* letter?
I bet you, and most (native, certainly) English speakers said it's the
*first* letter. STL's word choices are... a bit like writing code in
King James' English.


I do however feel that Qt's consistent use of verbs for actions and
non-verbs for properties (i.e. empty vs. isEmpty/is_empty) is far superior.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2016-07-01 17:56, Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
>> Even today: where is QList::push_back(T&&)? Where are our emplacement
>> functions and their try versions? Where are our exception guarantees?)
> 
> We don't care about exceptions, so we won't be adding those.
> 
> As for the move-versions, since we can't take move-only types in our 
> containers due to the implicit sharing, does it really make a difference if 
> we 
> have them or not?

Yes... and ironically, for the same reason implicit sharing is useful;
because the copy ctor might be horrendously expensive. Emplacement and
move-insert are (also) useful purely from a performance perspective.

> I would prefer the opposite: use non-Qt only if that is better than the Qt 
> equivalent. If you can't prove it or if it's too small, it's not worth the 
> difference in readability that it creates.

Option N+1: Convince the committee to adopt Qt's naming conventions and
convenience API's in STL2¹ ;-).

(¹ Or whatever it's being called...)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Edward Welbourne]

Thanks to Olivier for pointing out a mistake:

> I've fixed issues in qmake [0] where for-loops caused similar problems.
> [0] e.g. https://codereview.qt-project.org/#/c/161133

That should have been:
[0] https://codereview.qt-project.org#/c/141305/14//ALL,unified

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Edward Welbourne]

Stephen Kelly gave QQuickListViewPrivate::applyInsertionChange as an
example of "raw" for-loops being tricky to follow:

 There's a `++index` somewhere in the middle 3 scopes deep. Further
 up in the function `index` is assigned, but then assigned again
 (conditionally) from the `count` of a container. Then `index` is
 used later in the function, but I can't reason about what it is
 when it is used.

 There are many other problems with that function, which are caused
 by many 'raw' loops nested up to four levels, affecting variables
 assigned outside top-level if() conditions half a page
 up. Extracting such code into named functions would indicate the
 intent of the function.

I've fixed issues in qmake [0] where for-loops caused similar problems.
I *was* able to reason about them, but I made mistakes.  Fortunately, we
have some good disciplines like auto-testing and code-review, that
helped me notice them.

[0] e.g. https://codereview.qt-project.org/#/c/161133

Benjamin TERRIER opined:

>>> I'd boldly reply to that that if one is unwilling to reason about a
>>> piece of code, one should not be fixing it.

and yet, when I am tracking an elusive bug to its lair, I have to make
sense of all the pieces of code that I stumble upon in the course of my
hunt.  I may not be competent to fix it, but I have to be able to make
sense of it to determine *whether* it's the cause of my bug; and, even
if it isn't, I have to make enough sense of it to determine *how* its
eccentricities interact with the rest of the tangle of moving parts that
might be implicated in my bug.  I don't mind having to go to someone
else to get it fixed half as much as I do the problem of having to make
sense of whether it's to blame, when I'm not getting any response to my
e-mail to the author for help determining what part it plays in the bug
I'm chasing.  Each bug I hunt obliges me to make sense of way more
pieces of code than the roughly one that I actually end up having to
fix.

>>> But I'd also agree that the code should be as readable as possible
>>> to get a many developers to contribute.

+1.  Also: to waste as little of my time as possible.

>>> Back to Qt current situation I think that the lack of comments in
>>> some parts is a bigger throwback than the code style.

+1.  Sometimes code is solving a complex problem; then, it likely can't
help but *be* complex.  A gentle dusting of comments (and, in extreme
cases, a big fat overview-and-theory comment somewhere easy to find in
the right file) can go a long way towards helping the visiting
bug-hunter to make sense of the thicket they're stumbling through.

Stephen Kelly gave an example of some code I would complain about in
review, for quite other reasons than those he intended, and then said:

>> It is not possible to reason about code like that.

I attest, for the record, that I can reason about code like that.  Then
again, I came to C++ via a long history of C and some pre-history I'd
rather not talk about.  I know it can get tricky, and I'm glad you
didn't stoop to goto in your example.

>> I have the feeling that faced with code like that, people just don't
>> attempt to reason about it while at the same time trying to get on
>> with what they are trying to do.

There's always some code that's harder than others to make sense of.
Everything should be made as simple as possible - but no simpler.  When
solving a complex problem, the solution is apt to be likewise complex;
as long as its complexity is truly implied by the problem being solved,
this has to be OK.

>> Here's a recent example of a contributor responding exactly that way
>> to such code:

>> https://codereview.qt-project.org/#/c/161133

I fail to see a contributor responding the way you describe: you fixed
the problem - thank you - and you clearly reasoned about the code to do
so.  It ain't pretty, but you found something that worked.

>> The way to deal with functions like that is to extract loops and
>> other concepts into functions with names.

Breaking up long functions into conceptually compact parts is indeed a
recommended practice - and has been for decades.  This is uncontentious.
(Standard practice, in contrast, is some place else entirely - which is
why I do not regard software as an engineering discipline, yet.)

>> Delegating things like that has the effect of making the function
>> shorter. Adding comments instead would not have a positive effect on
>> the size of the function and good names are less likely to bitrot
>> than comments.

Sometimes a function mutates enough to make its name misguided - but
even so, that is more apt to be picked up in code review than comments
going stale.

>> In the above example you would start by extracting a qMaxValue
>> function.

... or just by calling some suitable .max() method on the container, if
it was sensibly defined.  This is a case of a standard pattern that any
API designer should take into account and that client code 

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

[Marc Mutz]

On Monday 04 July 2016 10:03:11 Philippe wrote:
> >>Actually, I disagree with that. As someone who has come to appreciate 
> >>STL after growing up in the Qt world,
> 
> Exact opposite here: I learned STL from its early days, and could never
> become at ease with its namings... and I started to breath with Qt
> containers :)

The value of the STL is not in the containers, it's in the algorithms.

We who use std containers in Qt would be on very thin ice if the Qt containers 
would stand an ice-balls chance in hell against the STL containers. But if 
using a std::deque in place of a QList speeds up code by 40%, then 
Qt has failed and either needs to fix its containers (impossible w/o abandoning 
CoW) or accept STL container use.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Somers]

Op 04/07/2016 om 10:03 schreef Philippe:

Actually, I disagree with that. As someone who has come to appreciate
STL after growing up in the Qt world,

Exact opposite here: I learned STL from its early days, and could never
become at ease with its namings... and I started to breath with Qt
containers :)

I'm not saying the namings are good, and I still find snake_case ugly. I 
dislike the use of abreviations, and yet, isEmpty() is way clearer than 
empty(). But the principles are very sound, especially the use of named 
algorithms over raw loops. Note that Qt has basicaly abandoned it's own 
algorithm collection for the stl one. That's mostly a Good Thing IMHO, 
though having your own collection of algorithms building on top of stl 
good practice I think. STL is by no means complete; you're encouraged to 
extend it. Defining a well-named free function to bridge the gap where 
it improves things is one way of enhancing both: you enhance STL by 
making it more readable to use, and you enhance Qt by embracing 
well-tested algorithms and containers.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Philippe]

>>Actually, I disagree with that. As someone who has come to appreciate 
>>STL after growing up in the Qt world,

Exact opposite here: I learned STL from its early days, and could never
become at ease with its namings... and I started to breath with Qt
containers :)

Philippe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Christian Kandeler]

On 07/01/2016 08:36 PM, Thiago Macieira wrote:

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 must admit I don't see a problem here. We are not talking about some 
random third-party library that people are pulling in gratuitously, but 
about the Standard Library, an integral part of C++ that every developer 
should be at least generally familiar with.
Having said that, I personally follow the "use Qt types by default" 
approach, but should we really regard STL containers as dangerous 
intruders that need to be kept out if at all possible?



Christian

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[André Somers]

Op 04/07/2016 om 08:41 schreef Thiago Macieira:

On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote:

Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
stl containers, implementing a free function qIsEmpty is less work and
addresses all your readability concerns.

But it is uglier
Actually, I disagree with that. As someone who has come to appreciate 
STL after growing up in the Qt world, I think that memberfunctions are 
over-used. Emptyness is a concept that can be applied to many objects, 
and it would be nice if I don't need a different function for all of 
them. The problem with implementing things in a member function is that 
the implementation will be specific for that class only, even if it did 
not really have to be. You end up re-creating algorithms for no good 
reason. And yes, that mistake has been made in the standard libraries as 
well.


Note that there is work going on by Bjarne S. on a universal calling 
conventions. As in: making calling a free function on an object and 
calling a member function on that object to be interchangeble in syntax.



and does not help with .append() for .push_back().


Why not? You could do the same thing there if you prefer.

append(Container c, T item) can be made to work for both STL and Qt 
containers I think?


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote:
> Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
> stl containers, implementing a free function qIsEmpty is less work and
> addresses all your readability concerns.

But it is uglier and does not help with .append() for .push_back().

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Julien Blanc]

Le samedi 02 juillet 2016 à 10:10 -0700, Thiago Macieira a écrit :
> On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote:
> > I don't get why you would be confused by - for instance - the empty
> > method.
> > STL has that method, but so does Qt [1] apparently in an attempt to be
> > compatible with the STL API.
> 
> That doesn't mean we will allow the use of those methods in our own 
> libraries. 
> I *will* reject any code that uses empty() to mean isEmpty() on a Qt 
> container.
> 
> The whole point of this thread is that using certain methods is misleading 
> or, 
> at best, confusing.

While I agree with you that isEmpty is a far better name than empty, I
don’t think renaming is the best idea.

As for the argument of using size() == 0 (which I prefer over renaming),
note that :
- std::forward_list does not have a size() member
- std::list size() may have linear complexity before C++11

About the example you gave, I see two things that could be improved,
with a much broader scope than just empty -> isEmpty (which is a
particular case) :

- the use of side-effects functions (aka : non const) in conditionals :
IMHO they’re bad for readability, especially if the condition is a bit
complex. If it is banned (or, banned unless commented), then there is no
ambiguity.
- visual distinction between const / non-const functions / variables
usages in QtCreator/whatever ide you’re using. This one would be a
must : the fact that empty is const makes it really clear what it does,
but you currently have to either know it or read the doc.

Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
stl containers, implementing a free function qIsEmpty is less work and
addresses all your readability concerns.

Regards,

Julien

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Jaroslaw Staniek]

On 1 July 2016 at 20:36, Thiago Macieira  wrote:

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


​[..]

Thanks for raising this topic, Thiago.
The topic resonates for me in the following way (as just a reader of the
code):

1. No doubt the algorithms and such improve our programming experience and
the simplifies activity that costs us most: reading/understanding the code
and intents. I'd applaud having the Option 3 and see Option 2 as nice to
have for future Qt.
Moreover I would happily consider using the wrappers (once stabilized
enough, they would be inline anyway?) in my projects out of the Qt source
tree. Sometimes I do consider adding that myself and like many others
probably already have a tiny bit of buried in my "utility" codes. That
would be no longer so much a necessity.

2. A mature C++ engineer shall not forget that the market average is way
below that level. I think it's not our intent to build a barrier for
contributors this way. I've seen a few projects that use no single
algorithm constructs, yet these are successful and mature projects. It's
unscientific but I recognize average level for a C/C++ programmer is way
below of level represented on this mailing list or boost/STL lists.
People have chosen Qt for simplicity _and_ consistency (no particular
order). Before knowing one or more typical profile of Qt contributors (like
personal in UX design?) it's too easy to assume everyone is so clever or on
its way to awesomeness.

3. I think it would be a good signal to the user base if Option 3 (or/and
then Option 2) would be communicated publicly that the Qt-ifed container
extensions will come to the public API. Not tomorrow but one day, like it
was the case with the QtJSEngine feature that started as a private
component. A next small-big thing from the Qt team.

4. I perceive *consistency in naming* as a higher value for a project than
potentially encouraging or winking at some "other" sub-communities to get
more people on board. A building block of a project is its internal coding
guideline. Qt is known from promoting consistency. I remember the
guidelines were used as a template in my professional work while creating
similar guidelines for others.
After all it's even a bit poisonous to compare release dates of projects.
E.g. Fortran or Visual Basic 1.0 predates HP's STL. Despite different
markets addressed, all of them are potentially interesting to build
contributor base; would it be sane to propose allowing for VB naming
schemes inside Qt? Or Fortran's?

Even if I am repeating someone else's observation, let's not forget: even
if a fraction of Qt's source code would contain bits familiar for
programmers thinking the "STL" way and having "STL" muscle memory, the
rest, the majority of the code follows the Qt guidelines. It's easy to
imagine single expressions or a simple code block that uses two naming
guidelines, usage of verbs/nouns, camel case, underscores. Some of that is
an aesthetic layer, some of that is more like provoking human errors. I bet
it can be independently measured how much effort it costs to switch between
naming while reading a single C++ block with mixed naming.[*]
And such code could not be too easily rejected in a code review.

Engineers are good at switching context once a while, but I am not sure
they are good at switching it every few seconds. Pros can cope with that,
75% of their efficiency is still very good, but that's just it.

I am afraid we would move to  discussions about where the borders are, how
to change our (currently) very good guideline document to address the
change. We would enter area where this (specific, dedicated) project has
not even two two approaches but a mix that's hard to clean up, and with no
way to undo.

[*] Extreme example of the mix is having HTML/JS/CSS/CSSS/PHP/Perl blocks
in one file.
​


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

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

[Stephen Kelly]

Thiago Macieira wrote:

> On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
>> to  qualify it, but there seems to me to be a much larger community
>> following modern C++ practices than following Qt practices on questions
>> like this.
> 
> The converse is also true

I agree, and I encourage you to raise std::empty as a problem

 http://en.cppreference.com/w/cpp/iterator/empty

so that it can be renamed to is_empty.  C++ developers should get 'is' in 
the name if that is the correct thing to do (ignore the camelCase/snake_case 
difference - that is orthogonal to the 'is' issue).

Giving that feedback that such a method must have 'is' in the name would be 
a valuable contribution from Qt experiences to the C++ community and work 
towards bridging the divide that I claimed exists (in both directions). 

> : by using auxiliary functions to do things where
> a simple loop would do, you're excluding a sizeable community that has
> never encountered those functions. Especially if those auxiliary types and
> functions have different and sometimes bewildering names, different from
> Qt's.

You can make Qt names for things. The important thing is that there is a 
name. Why don't we write 

 std::begin(container) == std::end(container)

everywhere? Because we named that concept 'emptiness'.

Consider this caricature of the kind of code that exists throughout Qt:

 int index = someFunctionParameter;
 int foo = containerOfIndexes.size();
 if (something) {
while (anotherThing) {
  if (foo % 2 == 0) {
++foo;
++index;
  }
}
 } else {
   ++foo;
 }

 while (foo) {
   if (bar && bang) {
 if (bang) {
   for (int i = 0, e = containerOfIndexes.size(); i != e; ++i) {
 if (index < containerOfIndexes[i]) {
   index = containerOfIndexes[i];
 }
   }
 }
 if (index < 0)
   break;
   }
 }

 return index;


It is not possible to reason about code like that. I have the feeling that 
faced with code like that, people just don't attempt to reason about it 
while at the same time trying to get on with what they are trying to do.

Here's a recent example of a contributor responding exactly that way to such 
code:

 https://codereview.qt-project.org/#/c/161133

The way to deal with functions like that is to extract loops and other 
concepts into functions with names. Delegating things like that has the 
effect of making the function shorter. Adding comments instead would not 
have a positive effect on the size of the function and good names are less 
likely to bitrot than comments.

In the above example you would start by extracting a qMaxValue function. You 
could implement that function in terms of std::max_element, or you could 
write a loop in the function if that's more comfortable. Even in the latter 
case, it is not a 'raw loop'. You have named a concept and using it will 
make other code more readable.

> Like you, I don't have numbers. But I can tell you one thing for sure:
> that community that follows non-Qt practices is not here.

I don't think that's true. People who do follow modern practices or boost do 
sometimes appear on this mailing list (and more than that read it - hello 
lurkers!). They don't tend to become long-term contributors though.

> It would be nice
> to attract them, but not at the expense of losing the people we already
> have and are familiar with Qt internals.

I think starting small to introduce the concepts and with Qt names like 
qMaxValue would work. Yes, learning and change would need to happen, but 
that can happen at whatever pace you choose. 

I'm not going to recommend replacing all loops with some Qt version of range 
adaptors starting tomorrow. 

There are many small steps which have benefits for readability.

>> I encourage you and everyone else to dive into it.
> 
> No, thanks.

I expect that, but I continue to encourage it (to everyone) anyway :).

Thanks,

Steve.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Stephen Kelly]

Thiago Macieira wrote:

> What do we do?

{
int container[1];
Q_ASSERT(!qIsEmpty(container));
}
{
std::vector container;
Q_ASSERT(qIsEmpty(container));
}
{
std::deque container;
Q_ASSERT(qIsEmpty(container));
}
{
std::list container;
Q_ASSERT(qIsEmpty(container));
}
{
std::forward_list container;
Q_ASSERT(qIsEmpty(container));
}
{
QVector container;
Q_ASSERT(qIsEmpty(container));
}
{
QList container;
Q_ASSERT(qIsEmpty(container));
}
{
QLinkedList container;
Q_ASSERT(qIsEmpty(container));
}
{
QString container;
Q_ASSERT(qIsEmpty(container));
}

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sábado, 2 de julho de 2016 13:11:32 PDT Sergio Martins wrote:
> On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> > 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.
> 
> and in some cases better readability too. For example, whenever you use
> cbegin, cfind, push_back you're writing code that's not only understandable
> by Qt developers but also C++ developers.
> 
> Lowering the bar for C++ developers to start contributing is important.
> I agree that STL also has many examples of worse readability, like very
> verbose algorithms. We should tackle this on a case by case basis.

See also my reply to Stephen on the same topic.

I agree with the logic, but I have to question the effort vs benefit.

This is the same question as with our CLA: how many developers are we turning 
away because of the issue? How many would make meaningful contributions if 
only the situation were different? You can extend this to other minor issues, 
like coding style (use of spaces instead of tabs) or even buildsystems ("I 
won't touch qmake").

I honestly do not see a horde of developers stopped at the gates of the API. I 
really don't think that's the case, as most of the developers willing to make 
contributions have usually used Qt and are somewhat familiar with our API. 
That is, the contributors usually are users of Qt that move upstream.

There are a few exceptions of developers moving downstream. For example, 
Wayland developers that come take a look at our code. How do we cater for both 
low-level C coders and for algorithms-using C++ coders?

> > 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());
> 
> "empty" is evil, I've fixed many places where the developer meant "clear()":

Yeah, except that here it *wasn't* clear(). It was "size() == 0" (isEmpty).

But I had to check.

> > What do we do?
> 
> What do we do to fix what ? First state the problem.
> You made a case against "empty" and then extrapolated to STL, as if you had
> a 3rd premise "STL is always less readable".

The situation (not everyone will agree there is a problem) is what I said at 
the beginning of my email and left quoted here: there's a flurry of new code 
using the Standard Library containers and algorithms. Do we do something about 
it?

Note that option 1 is status quo.

> > empty   ->  isEmpty
> 
> Agreed, it's error prone.
> 
> > push_back   ->  append
> > front   ->  first
> > pop_front   ->  takeFirst
> > cbegin  ->  constBegin
> > cfind   ->  constFind
> 
> Disagreed, the later form is the common denominator between C++ and Qt
> developers.

You mean the former, not latter.

Indeed, but my whole argument is that developers writing Qt code and, more 
importantly, those *reading* Qt code, are more familiar with the latter cases.

If the problem is only "empty", we can get around the problem by requiring 
"size() == 0" instead.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
> So, by sticking to lots of raw loops, you're actually actively excluding 
> other parts of the C++ community from participating. I don't have numbers
> to  qualify it, but there seems to me to be a much larger community
> following modern C++ practices than following Qt practices on questions
> like this.

The converse is also true: by using auxiliary functions to do things where a 
simple loop would do, you're excluding a sizeable community that has never 
encountered those functions. Especially if those auxiliary types and functions 
have different and sometimes bewildering names, different from Qt's.

Like you, I don't have numbers. But I can tell you one thing for sure: that 
community that follows non-Qt practices is not here. It would be nice to 
attract them, but not at the expense of losing the people we already have and 
are familiar with Qt internals.

> I encourage you and everyone else to dive into it.

No, thanks. You will also see me iterating over QChar and char instead of 
using those algorithms or even some of Qt's. See QUrlPrivate::parse, my recent 
changes to QTzTimeZonePrivate, for examples.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote:
> I don't get why you would be confused by - for instance - the empty
> method.
> STL has that method, but so does Qt [1] apparently in an attempt to be
> compatible with the STL API.

That doesn't mean we will allow the use of those methods in our own libraries. 
I *will* reject any code that uses empty() to mean isEmpty() on a Qt 
container.

The whole point of this thread is that using certain methods is misleading or, 
at best, confusing.

> Even if you don't want to learn or know how the STL API looks like, it
> should not matter since the very same members also apply on Qt containers
> with the same .
> This is the case for all your examples in Option 3.
> 
> Imho it would be nice - when using Qt and STL containers in the same
> statement - to use common functions that mean the same in both API's. Thus
> in your example both should have been empty() calls, even on the Qt
> container to be consistent. But that's just my opinion :)

I agree with your premise and the benefits in your conclusion. I just don't 
agree with using the Standard Library names, in detriment to Qt's own API. 

The whole point of Option 3 is to provide the Qt-like names so that we have 
*only* Qt-like names in Qt's source code. We'd achieve the same as you 
proposed (consistency) and we'd be consistent with the rest of the existing 
code as well as our recommended API.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Benjamin TERRIER]

2016-07-02 16:30 GMT+02:00 Stephen Kelly :
> Benjamin TERRIER wrote:
>
>> But how come a raw loop can be excluding? It should be understandable by
>> any C++ developer and, I would dare to say, by any C-style programming
>> language developer.
>
> I don't think anyone can understand or reason about raw-loop-heavy code (see
> PS below). I use 'excluded' to refer to people who are not willing to do so.
> They exclude themselves from working on Qt code because they can not reason
> about it.
>
> In the same sense, Thiago is 'excluded' from reading and understanding code
> which uses 'container.empty()' or which doesn't use raw-loops, because he
> would choose to not work on such code.
>
> There is a divide. The 'exclusion' is self-decided.
>
> Does that make sense? If you have a better phrase than 'self-exclusion' for
> that then it could be useful to share it.

Ok for me if you meant it this way.

> Someone unwilling to attempt to reason about the code in that function is
> 'excluded' from fixing something in it or extending whatever features it
> has.

I'd boldly reply to that that if one is unwilling to reason about a
piece of code, one should not be fixing it.
But I'd also agree that the code should be as readable as possible to
get a many developers to contribute.

Back to Qt current situation I think that the lack of comments in some
parts is a bigger throwback than
the code style.

And back to the actual topic of Qt/STL containers, I am for option 3
if the project can afford the
extra development and maintenance otherwise I'd go with option 4.

Br,

Benjamin Terrier
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Stephen Kelly]

Benjamin TERRIER wrote:

>> However, everyone else is excluded by it. When my colleagues find long
>> functions, lots of nested if()s and for()s, ++foo somewhere in while
> loops,
>> they find it much harder to reason about the code. Now I do too.
>>
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
> to
>> qualify it, but there seems to me to be a much larger community following
>> modern C++ practices than following Qt practices on questions like this.
> 
> You can't say that using raw loops (vs stl algorithms) is "actively
> excluding" any C++ developer.

Yes, maybe 'actively' was not correct.

> But how come a raw loop can be excluding? It should be understandable by
> any C++ developer and, I would dare to say, by any C-style programming
> language developer.

I don't think anyone can understand or reason about raw-loop-heavy code (see 
PS below). I use 'excluded' to refer to people who are not willing to do so. 
They exclude themselves from working on Qt code because they can not reason 
about it.

In the same sense, Thiago is 'excluded' from reading and understanding code 
which uses 'container.empty()' or which doesn't use raw-loops, because he 
would choose to not work on such code.

There is a divide. The 'exclusion' is self-decided.

Does that make sense? If you have a better phrase than 'self-exclusion' for 
that then it could be useful to share it.

Thanks,

Steve.

PS: Take QQuickListViewPrivate::applyInsertionChange as it is currently 
written as an example:

 
http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquicklistview.cpp?id=5d23470b#n3068

There's a `++index` somewhere in the middle 3 scopes deep. Further up in the 
function `index` is assigned, but then assigned again (conditionally) from 
the `count` of a container. Then `index` is used later in the function, but 
I can't reason about what it is when it is used.

There are many other problems with that function, which are caused by many 
'raw' loops nested up to four levels, affecting variables assigned outside 
top-level if() conditions half a page up. Extracting such code into named 
functions would indicate the intent of the function.

Someone unwilling to attempt to reason about the code in that function is 
'excluded' from fixing something in it or extending whatever features it 
has.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Olivier Goffart]

On Freitag, 1. Juli 2016 14:56:36 CEST Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> > Even today: where is QList::push_back(T&&)? Where are our emplacement
> > functions and their try versions? Where are our exception guarantees?)
> 
> We don't care about exceptions, so we won't be adding those.

Ok.

> As for the move-versions, since we can't take move-only types in our
> containers due to the implicit sharing, does it really make a difference if
> we have them or not?

Well, you point out another weakness of our contaners (not supporting move-
only types).
But even then, the push_back(T&&) overload or emplace functions would still 
usefull to avoid an uneeded copy in some cases. (possibly saving memory 
alocations)

[...]
> > Which again seems like a sensible thing to do in general, unless there
> > are documented cases in which Qt containers significantly outperform STL
> > ones (apart from implicit sharing).
> 
> I would prefer the opposite: use non-Qt only if that is better than the Qt
> equivalent. If you can't prove it or if it's too small, it's not worth the
> difference in readability that it creates.

I think you have an unjustified bias against the STL.
With the exception of "empty", you are overestimating the readability problem 
it pauses.

You also write in another email on this thread:
> You will always see me write a for-loop to fill something rather than use
> std::fill.

And I think you are making a mistake.

Consider:

a)
 std::fill(vec.begin(), vec.end(), computeBackgroundColor());

b)
 for(int i = 0; i < vec.size(); i++)
   vec[i] = computeBackgroundColor();

c)
 auto backgroundColor = computeBackgroundColor();
 for (auto it = vec.begin(); it != vec.end(); ++it)
   *it = backgroundColor;


Personally I find that a. is more readable, as it is objectively more concise 
and cearly express the intent.  b. has some overhead.
Conciseness is important as it reduce the likelyhood of mistake. Also more 
code means more time to read it.

It is true that a lot is a matter of taste, but I totaly buy the reasoning 
behind the "no raw loop".

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Benjamin TERRIER]

> However, everyone else is excluded by it. When my colleagues find long
> functions, lots of nested if()s and for()s, ++foo somewhere in while
loops,
> they find it much harder to reason about the code. Now I do too.
>
> So, by sticking to lots of raw loops, you're actually actively excluding
> other parts of the C++ community from participating. I don't have numbers
to
> qualify it, but there seems to me to be a much larger community following
> modern C++ practices than following Qt practices on questions like this.

You can't say that using raw loops (vs stl algorithms) is "actively
excluding" any C++ developer.
I would agree to say that simplifying code by using STL makes the code more
readable for developers used to the STL. And that raw loops and nested
controls can be less readable.
But how come a raw loop can be excluding? It should be understandable by
any C++ developer and, I would dare to say, by any C-style programming
language developer.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Mark Gaiser]

On Fri, Jul 1, 2016 at 8:36 PM, Thiago Macieira 
wrote:

> 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
>
> I don't get why you would be confused by - for instance - the empty method.
STL has that method, but so does Qt [1] apparently in an attempt to be
compatible with the STL API.

Even if you don't want to learn or know how the STL API looks like, it
should not matter since the very same members also apply on Qt containers
with the same .
This is the case for all your examples in Option 3.

Imho it would be nice - when using Qt and STL containers in the same
statement - to use common functions that mean the same in both API's. Thus
in your example both should have been empty() calls, even on the Qt
container to be consistent. But that's just my opinion :)

[1] http://doc.qt.io/qt-5/qlist.html#empty
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Sergio Martins]

On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> 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.

and in some cases better readability too. For example, whenever you use 
cbegin, cfind, push_back you're writing code that's not only understandable by 
Qt developers but also C++ developers.

Lowering the bar for C++ developers to start contributing is important.
I agree that STL also has many examples of worse readability, like very 
verbose algorithms. We should tackle this on a case by case basis.

> 
> 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());
> 

"empty" is evil, I've fixed many places where the developer meant "clear()":

https://quickgit.kde.org/?
p=kdelibs4support.git&a=commit&h=c27b851e62307dd16780bf94aff8e6c650ac8dc7

I think we should even remove QList::empty() in Qt6, we want STL compat with 
the good things, not the bad things.

> What do we do?

What do we do to fix what ? First state the problem.
You made a case against "empty" and then extrapolated to STL, as if you had a 
3rd premise "STL is always less readable".

>   empty   ->  isEmpty

Agreed, it's error prone.

>   push_back   ->  append
>   front   ->  first
>   pop_front   ->  takeFirst
>   cbegin  ->  constBegin
>   cfind   ->  constFind

Disagreed, the later form is the common denominator between C++ and Qt 
developers.


Regards,
Sérgio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Stephen Kelly]

Stephen Kelly wrote:

> Thiago Macieira wrote:
> 
>> More to the point, Qt developers don't have to know the Standard Library.
>> *I* don't and I don't have time or interest in learning it.
> 
> There is a big division within the C++ community. There is the Qt way and
> the non-Qt way, and they don't overlap.

This is the real point of my email. There is division along a Qt and non-Qt 
boundary on things like this. 

It is analogous to different sides voting in a referendum: Each side is 
completely perplexed with the other and can't understand their thinking, 
thinks the other side is 'stupid' or otherwise low-quality, and doesn't want 
to waste time understanding it.

For people who learn programming and learn C++ by learning Qt (myself 
included), the Qt implementation seems familiar with all the raw loops if 
you have never encountered the alternative.

However, everyone else is excluded by it. When my colleagues find long 
functions, lots of nested if()s and for()s, ++foo somewhere in while loops, 
they find it much harder to reason about the code. Now I do too. 

So, by sticking to lots of raw loops, you're actually actively excluding 
other parts of the C++ community from participating. I don't have numbers to 
qualify it, but there seems to me to be a much larger community following 
modern C++ practices than following Qt practices on questions like this.

I encourage you and everyone else to dive into it.

Thanks,

Steve.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Stephen Kelly]

Thiago Macieira wrote:

> More to the point, Qt developers don't have to know the Standard Library.
> *I* don't and I don't have time or interest in learning it.

There is a big division within the C++ community. There is the Qt way and 
the non-Qt way, and they don't overlap.

The approach of many raw loops and no algorithms is taken often in Qt 
implementation (and documentation).

On the other side of the dividing line is people who value boost::irange, 
boost::indexed_range, boost::max_element and others.

As someone who 'crossed over' to the range/algorithm/stl way after starting 
at Ableton, I can say I prefer it greatly.

Here is a patch from me which fixes two bugs in one line of code (which I 
wrote several years previously):

 https://quickgit.kde.org/?p=kitemmodels.git&a=commitdiff&h=49609b8b53

Those kinds of bugs don't occur if you use algorithms instead of nested 
loops. Classes of bugs get eliminated:

 for (auto j = 0; j <= model->rowCount(); ++i) { // Double oops!

 }

 for (auto row : boost::irange(0, model->rowCount()) { 

 }

Yes, code could still mistakenly use `i` inside the loop, but that is a 
different class of bug which would be present in both cases (and the 
solution is more scoping by extracting named functions).

Thanks,

Steve.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Denis Shienkov]

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



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Philippe]

> The only thing worse than code you don't understand is code that you 
> misunderstand.

Very wise remark !

> STL was standardized 18 years ago, I think it should be enough to get used to 
> empty().

A bad name remains a bad name. The mind has more important energy to
spend than "getting used to".

Option 3 has my vote.

Philippe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Sune Vuorela]

On 2016-07-01, Thiago Macieira  wrote:
> 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. 

Hah. I found some code in a large project the other day. The code is a
monstrosity of stl, mfc and qt code.
There was an empty() function. It returned void. and was not const.

Yes. it was clearing its internal collections and states.

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sábado, 2 de julho de 2016 08:42:42 PDT Marc Mutz wrote:
> This sort of sentiment fosters mistakes such as looping over
> QVector::erase(it), turning a linear operation quadratic, and people trying
> to reimplement binary search, leading to unstable search results that
> depend on the size of the container. IOW: bugs.
> 
> Yes. I'm saying: Less STL use == more bugs.

Which is why I grudgingly accept std::erase + std::remove_if, despite being 
ugly-to-read code.

> We should instead foster the use of STL algorithms ("No raw loops"), not use
> ignorance of the greatest C++ library ever written as a reason not to use
> what it has to offer.

If there's no difference in performance, I prefer the raw loop.

> About APIs:
> 
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It
> just happens to be largely consistent with itself instead of with Qt. But
> camelCase is not intrinsically "better" than underscored_names, and I also
> fail to see why first() should be intrinsically superior to front().

Intrinsically, neither is superior to the other. But that was not my point.

My point is that inside Qt, Qt API is more readable than the Standard Library 
API because one is consistent with the rest of the code, the other isn't.

> And as an aside: please stop claiming that "the Qt API was there before the
> STL one".

I claimed that Qt had its API published before the C++ standard was out. I 
know that SGI had published STL before the standard.

> Tell the world how the Qt containers looked when the STL was released. Go
> on. If you want Qtsy containers, go back _there_. The current Qt containers
> are more STLsy than Qtsy, and they're better for it.

The API style is pretty much the same and this is my only point here: API and 
consistency.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sábado, 2 de julho de 2016 07:46:28 PDT Marc Mutz wrote:
> Don't make this about the STL. Your arguments trivally extend to any third-
> party code.
> 
> So what you are actually proposing is to not use any third-party code in Qt
> unless it is wrapped in a Qtsy API first.

Not exactly. The Standard Library API is close enough to Qt's that it could be 
mistaken for Qt's, but subtly different. No one will mistake the Win32 API, 
Objective C API or, for that matter, any C library's API for Qt's.

The only thing worse than code you don't understand is code that you 
misunderstand.

> This is a bit over the top, isn't it? We want to allow our users to stay in
> the cozy Qt bubble for their own projects. As implementers of that bubble,
> we have no right to stay in it ourselves if doing so would be to the
> detriment of our users. And even creating an API wrapper is to the
> detriment of our users, because it requires resources that are then no
> longer available to fix real problems.

I get your point: we'd spend resources on something other than fixing real 
things. My counter point is that creating these wrappers increases our 
productivity. At the very least, it increases mine.

> If this is straw poll, I'm voting for Option 5. C++ programmers (those that
> wish to implement a C++ library) should be familiar with the STL.

In my opinion, Qt's existence negates your reasoning: we are creating a set of 
libraries that allow users not to know the Standard Library. And I am a 
product of that generation, as are many of our own developers.

Anyway, for the record, I vote for option 3: create simple wrappers. I will 
volunteer to do them too, if this is the option we choose.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 01 July 2016 22:05:45 Thiago Macieira wrote:
>  I 
> don't and I don't have time or interest in learning it. You will always see
> me  write a for-loop to fill something rather than use std::fill.

This reminds of the party quip: "I was always bad at math in school " 
:)

But seriously:

This sort of sentiment fosters mistakes such as looping over 
QVector::erase(it), turning a linear operation quadratic, and people trying to 
reimplement binary search, leading to unstable search results that depend on 
the size of the container. IOW: bugs.

Yes. I'm saying: Less STL use == more bugs.

We should instead foster the use of STL algorithms ("No raw loops"), not use 
ignorance of the greatest C++ library ever written as a reason not to use what 
it has to offer.

About APIs:

The STL has a great API. push_back() / back() vs. append() / last(), e.g. It 
just happens to be largely consistent with itself instead of with Qt. But 
camelCase is not intrinsically "better" than underscored_names, and I also 
fail to see why first() should be intrinsically superior to front().

And as an aside: please stop claiming that "the Qt API was there before the 
STL one".

Tell the world how the Qt containers looked when the STL was released. Go on. 
If you want Qtsy containers, go back _there_. The current Qt containers are 
more STLsy than Qtsy, and they're better for it.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Marc Mutz]

On Friday 01 July 2016 20:36:56 Thiago Macieira wrote:
> 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.

Don't make this about the STL. Your arguments trivally extend to any third-
party code.

So what you are actually proposing is to not use any third-party code in Qt 
unless it is wrapped in a Qtsy API first.

This is a bit over the top, isn't it? We want to allow our users to stay in 
the cozy Qt bubble for their own projects. As implementers of that bubble, we 
have no right to stay in it ourselves if doing so would be to the detriment of 
our users. And even creating an API wrapper is to the detriment of our users, 
because it requires resources that are then no longer available to fix real 
problems.

If this is straw poll, I'm voting for Option 5. C++ programmers (those that 
wish to implement a C++ library) should be familiar with the STL.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sexta-feira, 1 de julho de 2016 18:31:17 PDT Rafael Roquetto wrote:
> Of course, all this assumes the introduction of a QtStl namespace to be a
> feasible task. Whether it really is I cannot say.

I'd say we start with it in a private header, add classes to it as needed. If 
we're happy with it, then we can consider making it public, later.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> Even today: where is QList::push_back(T&&)? Where are our emplacement
> functions and their try versions? Where are our exception guarantees?)

We don't care about exceptions, so we won't be adding those.

As for the move-versions, since we can't take move-only types in our 
containers due to the implicit sharing, does it really make a difference if we 
have them or not?

> >> 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
> > 
> > Of course, Option 4:
> > Continue to allow Standard Library containers in internal code (no API or
> > ABI constraining) where there's a clear gain in performance and/or size.
> 3 and 4 actually don't conflict, do they? If we subclass STL containers
> (say, in a QtStl namespace) and add those inline functions we would
> still be using them in the end. But before going this way, is it
> possible to estimate the amount of work to get this in place?

The difference is the API used elsewhere in our code.

The amount of work should be minimal. There's just a handful of functions that 
need different names, plus two more like takeFirst and takeLast that do two 
things in one.

> > Option 5:
> > Allow Standard Library containers in internal code even if performance or
> > code size gains are not appreciable or have not been measured.
> 
> Which again seems like a sensible thing to do in general, unless there
> are documented cases in which Qt containers significantly outperform STL
> ones (apart from implicit sharing).

I would prefer the opposite: use non-Qt only if that is better than the Qt 
equivalent. If you can't prove it or if it's too small, it's not worth the 
difference in readability that it creates.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Rafael Roquetto]

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


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Matthew Woehlke]

On 2016-07-01 16:13, Giuseppe D'Angelo wrote:
> Even today: where is QList::push_back(T&&)? Where are our emplacement
> functions and their try versions? Where are our exception guarantees?)

...what's an exception? ;-) Never heard of those in Qt...

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Giuseppe D'Angelo]

Howdy,

Il 01/07/2016 21:34, Thiago Macieira ha scritto:

On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:

Option 1:
Not use Standard Library containers, just use the Qt containers as they
exist.


However this is an anti-goal. As you stated, STL containers usage inside 
Qt is increasing for very good reasons. In the case in question, there 
isn't even a Qt equivalent for std::deque, and I don't see one coming 
anytime soon. (And even so, is it really going to outperform a container 
which has been around, studied, profiled, optimized, instrumented, for 
15+ years?)



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.


Again, also this looks like a massive anti-goal. I don't think we should 
invest any resource in this massive effort that reinvents the wheel, 
just for the sake of renaming a few functions.


(... not to mention that is extremely likely that we will always lag 
behind the current Standard and perform worse than any other STL 
implementation under any possible benchmark.


Even today: where is QList::push_back(T&&)? Where are our emplacement 
functions and their try versions? Where are our exception guarantees?)




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


Of course, Option 4:
Continue to allow Standard Library containers in internal code (no API or ABI
constraining) where there's a clear gain in performance and/or size.


3 and 4 actually don't conflict, do they? If we subclass STL containers 
(say, in a QtStl namespace) and add those inline functions we would 
still be using them in the end. But before going this way, is it 
possible to estimate the amount of work to get this in place?




Option 5:
Allow Standard Library containers in internal code even if performance or code
size gains are not appreciable or have not been measured.


Which again seems like a sensible thing to do in general, unless there 
are documented cases in which Qt containers significantly outperform STL 
ones (apart from implicit sharing).


IIRC, when there was the big thread about whether allowing STL 
containers or not in Qt implementation, people did such benchmarks and 
the results were always in favour of STL. Can anyone find the relative 
links...?


My 2 cents,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

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

More to the point, Qt developers don't have to know the Standard Library. *I* 
don't and I don't have time or interest in learning it. You will always see me 
write a for-loop to fill something rather than use std::fill.

Qt users don't have to learn it either. If they read the Qt source code, they 
should understand it. They might do that because they were debugging their 
application and stepped into Qt to find out what's happening.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

01.07.2016, 21:37, "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.

STL was standardized 18 years ago, I think it should be enough to get used to 
empty().

>
> 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
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
> 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

Of course, Option 4:
Continue to allow Standard Library containers in internal code (no API or ABI 
constraining) where there's a clear gain in performance and/or size.

Option 5:
Allow Standard Library containers in internal code even if performance or code 
size gains are not appreciable or have not been measured.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development