Re: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions

[Smith Martin]

I have Xcode 7.2.1 and OSX 10.11.3 installed, but my Xcode isn't allowing me to 
compile qdoc. The compiler says it can't find things like #include , 
which means it isn't installed correctly. But I have no idea what's wrong.


martin



From: Development 
 on behalf of 
Halmet Heikki 
Sent: Friday, March 18, 2016 9:34 AM
To: Heikkinen Jani; development@qt-project.org
Cc: releas...@qt-project.org
Subject: Re: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool 
versions


Hi,



I think we also need to update at least these to 5.7

Xcode 7.2.1 to OSX 10.10.5 & 10.11.2

Xcode 6.2 to OSX 10.9.4

Android sdk 24.4.1

Visual Studio 2015 Update 1 to Windows 10

Latest openssl 1.0.2g



Should we use beta OSX and  beta Xcode in dev?

Xcode 7.3 beta 5 to OS X v10.11.4 beta



- Heikki





From: Development 
[mailto:development-bounces+heikki.halmet=theqtcompany@qt-project.org] On 
Behalf Of Heikkinen Jani
Sent: 18. maaliskuuta 2016 10:03
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions



Hi all,



Currently used tools & versions in ci and packaging are listed in 
http://wiki.qt.io/Qt-5.7.0-tools-and-versions.  'dev' is also using same set.



Now when Qt 5.6.0 is out we are planning to do some updates. We are planning to:



- Update MinGW to i686-5.3.0-release-posix-dwarf-rt_v4-rev0

* first test build already done by Kai, full test build to be done in coin 
really soon



- Update Android NDK to r11

* Some build issue reported 
(QTBUG-51859), fix 
https://codereview.qt-project.org/#/c/153212/

Please inform me immediately if you see some problem with this. Also inform me 
immediately if you know something else to be updated (for 5.7 or for 5.8). For 
5.7 we are already quite late and we need to get needed updates done before 
beta release. For 5.8 it is actually correct time to do those ;)

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

Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++

[Smith Martin]

I'm stating it now. What is your objection?


martin



From: Development 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Karsten Heimrich <karsten.heimr...@digia.com>
Sent: Thursday, February 25, 2016 12:08 PM
To: development@qt-project.org
Subject: Re: [Development] We are planning to upgrade qdoc to use clang for 
parsing C++


Hi,



From: Development 
[mailto:development-bounces+karsten.heimrich=theqtcompany@qt-project.org] 
On Behalf Of Cristian Adam
Sent: Donnerstag, 25. Februar 2016 11:20 Uhr
To: Smith Martin <martin.sm...@theqtcompany.com>
Cc: development@qt-project.org
Subject: Re: [Development] We are planning to upgrade qdoc to use clang for 
parsing C++





On Thu, Feb 25, 2016 at 10:56 AM, Smith Martin 
<martin.sm...@theqtcompany.com<mailto:martin.sm...@theqtcompany.com>> wrote:

Send ideas for upgrading the Qt documentation to C++11.



1. Which C++11 constructs will be used in Qt?



2. Which of these should appear in the documentation?



Send comments to the CC list.



Since qdoc will be using libclang, any change of getting the same treatment for 
moc?



I've heard these now several times without finding any reasonable source for 
the rumor. Can please someone point me to the place where this is stated.



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

Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++

[Smith Martin]

I mean, for example, if a class is "final" how should this be stated in the 
documentation? Should qdoc automatically include "This class may not be used as 
a base class." or should qdoc just include the word "final" in the title?

martin


From: Nowacki Jedrzej
Sent: Thursday, February 25, 2016 11:10 AM
To: development@qt-project.org
Cc: Smith Martin
Subject: Re: [Development] We are planning to upgrade qdoc to use clang for 
parsing C++

On Thursday 25 of February 2016 09:56:01 Smith Martin wrote:
> Send ideas for upgrading the Qt documentation to C++11.
>
> 1. Which C++11 constructs will be used in Qt?
All of them, in longer run C++14 too :-)

> 2. Which of these should appear in the documentation?
I do not understand the question. All of them that are documented?

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

[Development] We are planning to upgrade qdoc to use clang for parsing C++

[Smith Martin]

Send ideas for upgrading the Qt documentation to C++11.


1. Which C++11 constructs will be used in Qt?


2. Which of these should appear in the documentation?


Send comments to the CC list.


martin


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

Re: [Development] Documentation for methods of QML basic type

[Smith Martin]

qdoc doesn't support it yet, because it wasn't done before. 

I will add it.

martin


From: Development  on behalf of Nikita 
Krupenko 
Sent: Saturday, February 13, 2016 2:24 AM
To: development@qt-project.org
Subject: [Development] Documentation for methods of QML basic type

Hi all!

I'm working on adding methods to basic QML type (color) and I need to
document it. What qdoc tags should I use for this methods to be
included into doc? I tried to use "\qmlmethod" but it does not work
(or I do something wrong).

I have suspicion, that qdoc does not support documenting methods of
QML basic type. Is it even possible to document methods not only for
"\qmlclass" but for "\qmlbasictype" too? I have not found any examples
of such use case in Qt sources.
___
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] Doc: Making it easier for devs to know if a class is supported on a given platform

[Smith Martin]

I suppose the default should be that a class is fully supported on all Qt 
platforms, so the qdoc command should be \notsupported with the list of not 
supported platforms.


\notsupported 


...could appear in a \class or a \fn or in a \qmltype or \qmlmethod.


martin



From: Development  on behalf of Sze Howe 
Koh 
Sent: Saturday, January 23, 2016 4:30 AM
To: development@qt-project.org
Subject: [Development] Doc: Making it easier for devs to know if a class is 
supported on a given platform

Hi all,

With the proliferation of supported platforms and add-on modules, we now have a 
situation where some classes are only useable on particular platforms. There've 
been cases where a developer sees a class in the Qt docs and thinks "Ooh, this 
is just what I need!", only to find out (after spending time studying examples 
and writing code) that the class can't be used on their platform of interest. 
[1]

It would be nice to help them find out earlier whether a class is available or 
not.

We currently have some documentation, e.g. http://doc.qt.io/qt-5/qtmodules.html 
lists "Target Platforms" for add-on modules. However, a user who finds the 
class ref via a search engine might miss this.
All Modules | Qt 5.5
doc.qt.io
If you use qmake to build your projects, the Qt Core and Qt GUI modules are 
included by default. To link only against Qt Core, add the following line to 
your .pro file:



One idea is to add a "Target Platforms" row in the class reference, below the 
"Header", "qmake", and "Inherits" rows. qdoc could populate this for each class 
based on info provided about the module.

However, we have a situation in Qt Multimedia where the module is broadly 
available, but particular features are not: 
https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is available 
on iOS but QAudioProbe is not.

The previous idea for an auto-populated "Target Platforms" row would be 
erroneous in this case. Perhaps we could have a per-class "\supports" qdoc 
command, or even manually type in a line saying "This class is (not) supported 
on _"? (I'm happy to spend time doing this, but it's not a very 
maintainable solution)

Any other thoughts/ideas? (I haven't thought through QML types yet)


Regards,
Sze-Howe

[1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Smith Martin]

Here is a JIRA task for it:
https://bugreports.qt.io/browse/QTBUG-50548


From: Development  on behalf of Marc Mutz 

Sent: Wednesday, January 20, 2016 11:58 AM
To: development@qt-project.org
Subject: Re: [Development] QStringLiteral vs QLatin1String ,foreach vs for 
range

On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> > Where is this qAsConst coming from? When was it introduced? Where is it
> > documented?
>
> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

It was intended as private API for use within Qt. If the sentiment is that it
should be public, I'll add proper docs.

If the sentiment is also that we should start to discourage the use of
Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Question about QCoreApplicationData::*_libpaths

[Smith Martin]

>No-one, not even experts understand QList, really. So it may appear to be easy
>to use, but is actually a container only absolute experst should use.

Marc, you are still conflating optimal runtime efficiency with algorithmic 
correctness. QList is easy to use correctly in algorithms. It is almost hard to 
make a mistake. That is all "easy to use" means. It doesn't mean "easy to use 
while achieving optimal runtime efficiency."

You can't judge all programmers using your encyclopaedic knowledge as the 
standard. There is a lot to be learned by doing things correctly the easy way. 
It even makes learning to do the same things with optimal runtime efficiency 
more meaningful.

martin



From: Development  on behalf of Marc Mutz 

Sent: Tuesday, January 19, 2016 11:52 AM
To: development@qt-project.org
Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths

On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote:
> On 15/01/16 23:20, "Development on behalf of Thiago Macieira"  wrote:
> >On Friday 15 January 2016 18:42:43 Marc Mutz wrote:
> >> And you will see it over and over again until enough people are fixing
> >> premature pessimisations in existing Qt code. There's a notable increase
> >> already. But it takes a long time to turn a supertanker around...
> >
> >Some of us call them "trade-offs". Every trade-off is a pessimisation
> >somewhere for an optimisation somewhere else. Often, they're not measured
> >in the same units or not quantifiable at all.
> >
> >API quality and consistency fall under those definitions.
>
> Exactly this.
>
> >> And no, I cannot believe that using the Qt containers leads to faster
> >> applications. It may lead to applications faster, but not to faster
> >> applications.
> >
> >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20
> >rule).
>
> And this. Let’s not forget to ask ourselves the question why many
> developers use Qt in C++ development, often even in the case where they
> don’t need a UI. For the past 20 years a lot of our focus has been on
> making development easy, and creating APIs that serve that goal. This
> means that we are in many case optimising for TTM more than for ultimate
> speed.
>
> I think we agree that std containers are in many cases faster than the Qt
> containers. But they are harder to use and especially developers that come
> from other languages often appreciate the ease of use of the Qt
> containers.

I always cringe when I hear this. What, specifically, do you mean by "easier to
use"?

No-one, not even experts understand QList, really. So it may appear to be easy
to use, but is actually a container only absolute experst should use.

And a QVector provides exactly the same guarantees as a std::vector. How come
one is easier to use than the other? Because QVector has indexOf()? And what
about those cases where the user wants to find an element by just a field? They
will write for loops, most likely, and not use algorithms.

The crucial point here is that there's no "better" Qt API for this than what
exists on std::vector. Instead, there's a much more complicated API by sheer
volume and duplication, without being near extensive enough for even very
simple tasks. At some point, the question must be asked whether CoW and
append() vs. push_back() do not become more of a burden than a merit. And
whether we need three names for size().

> The main question IMO is how we can bring these two worlds closer together
> for Qt 6 (or maybe even to some extent in Qt 5.x).

My answer would be to use std containers exclusively, and write a wagonload
full of Qt-level docs about them, ie. integrate them into the Qt docs.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Question about QCoreApplicationData::*_libpaths

[Smith Martin]

>I disagree that an easy-to-use class has any business 
>providing completly opposing semantics for QList, simply based on 
>whether you compile for 64-bits or 32.

It doesn't, but it doesn't make QList less easy to use either. 


From: m...@kdab.com <m...@kdab.com> on behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Tuesday, January 19, 2016 1:23 PM
To: Smith Martin
Cc: development@qt-project.org
Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths

On Tuesday 19 January 2016 11:44:44 Smith Martin wrote:
> Marc, you are still conflating optimal runtime efficiency with algorithmic
> correctness. QList is easy to use correctly in algorithms. It is almost
> hard to make a mistake. That is all "easy to use" means. It doesn't mean
> "easy to use while achieving optimal runtime efficiency."

See my reply to Harri. I disagree that an easy-to-use class has any business
providing completly opposing semantics for QList, simply based on
whether you compile for 64-bits or 32.

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

Re: [Development] RFC: more liberal 'auto' rules?

[Smith Martin]

+1

martin


From: Development  on behalf of Randall 
O'Reilly 
Sent: Friday, December 04, 2015 8:35 AM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

This debate between the std:: lib and wider C++ community vs. the Qt traditions 
seems never-ending :)  At the risk of perpetuating the inevitable flame war, my 
perspective is well captured in this article:  
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++ is WAY too complex of a language, and other alternatives are rapidly 
gaining users (particularly Python in the domain of scientific computing).  The 
STL and its sea of recursive templates has in particular been incredibly 
daunting.  C++11 helps, but the complexity remains..

Of course, there is no “right” answer in any of these language debates: only 
different people optimizing different ends of many different fundamental 
tradeoffs.

C and C++ in general tend to attract people who favor optimization over 
simplicity / usability of the language.  Marc is clearly in that camp, 
advocating many ways of optimizing performance..  With all the new language 
options, presumably those that stick with C++ are even more apt to be obsessed 
with performance..

But Qt is beloved by many (myself included) because it provides a *simple*, 
elegant, well-designed, well-named API, that does a lot of stuff..  Not because 
of its optimal performance or cutting-edge language features and adherence to 
the C++ standard..

I got “stuck” in C++ for historical reasons: it was the only viable option for 
object-oriented programming in the 1990’s.  Sure, I care about optimization for 
my critical inner loops.  But for everything else, I really wish it was a lot 
simpler.  And again, I value Qt for making it so in the GUI, which consumes a 
huge amount of my code, and has minimal performance demands, because it is a 
GUI and the human in the loop is almost always the rate limiting factor.  Of 
course we don’t want exponential slowdowns with large numbers of Widgets etc, 
but I’ve never found that to be a problem in Qt.

So anyway, this is just a vote to keep with the solid tradition of favoring 
simplicity, clarity, usability, readability, etc, instead of just following the 
std:: C++ crowd!  Without Qt, I would have to suck it up and rewrite everything 
in Go or Python or something.. :)

- Randy

> On Dec 4, 2015, at 12:49 AM, Marc Mutz  wrote:
>
> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
>>> That depends on how big the remainder is. I argue that we're relevant
>>> enough  that our own direction is big enough to be of relevance.
>>
>> That didn't come out right. Rephrasing:
>>
>> Qt has enough market share by itself that we can choose our own direction
>> and still be relevant. We are allowed to disagree with what others do.
>
> Yes, but only if we know *better*.
>
> I very much doubt that more than very few people in Qt development have the
> knowledge to objectively overrule the accepted C++ authorities. I myself have
> seen over and over again that how I thought a feature should be used was blown
> to smithereens by members of the committee, usually rightfully so.
>
> So the default should be to follow what the greater C++ community is doing,
> while *divergence* from that needs to be argued for.
>
> Everything else is approaching hubris, imo.
>
>> we don't use exceptions
>
> ...and look at the sorry state of error handling in Qt - every class does it
> differently... It's ok not to use exceptions, but not having a consistent 
> error
> handling strategy doesn't put us into a position to throw that stone.
>
>> we don't use underscores
>
> ... except we do (grep "qt_"). And there's *nothing* wrong with that!
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

I see. But then, if I have QStringView, doesn't that eliminate most of the 
reasons for needing the other string containing classes? If I want the 
efficiency of QStringView, won't QString underneath always be the right choice?

In Thiago's example, if I have a QStringView API on my class, would I ever want 
to switch the QString to a QByteArray?

Does using QStringView with QString work as well or better than WByteArray et 
al?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Marc Mutz <marc.m...@kdab.com>
Sent: Monday, October 19, 2015 11:26 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> >This API here simply cannot exist because the returned value would be a
> >dangling reference.
>
> I don't understand. Implicit for using the QStringView data() function is
> knowing that once the QByteArray is set, it is never changed. Then the
> data() function is ok, isn't it?

A QStringView points to QChar* (or ushort*) while a QByteArray only provides
char*. The fromLatin1() (say) call thus necessary will create a temporary
QString, which will bind to the returned QStringView, but will already be
destroyed (taking the data QStringView references with it) when control
returns to the caller.

This particular mistake is easy to prevent statically, though:

   QStringView(QString &&) = delete;

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

That's QByteArray at the end, of course.


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Smith Martin <martin.sm...@theqtcompany.com>
Sent: Tuesday, October 20, 2015 9:13 AM
To: Marc Mutz; development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

I see. But then, if I have QStringView, doesn't that eliminate most of the 
reasons for needing the other string containing classes? If I want the 
efficiency of QStringView, won't QString underneath always be the right choice?

In Thiago's example, if I have a QStringView API on my class, would I ever want 
to switch the QString to a QByteArray?

Does using QStringView with QString work as well or better than WByteArray et 
al?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Marc Mutz <marc.m...@kdab.com>
Sent: Monday, October 19, 2015 11:26 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> >This API here simply cannot exist because the returned value would be a
> >dangling reference.
>
> I don't understand. Implicit for using the QStringView data() function is
> knowing that once the QByteArray is set, it is never changed. Then the
> data() function is ok, isn't it?

A QStringView points to QChar* (or ushort*) while a QByteArray only provides
char*. The fromLatin1() (say) call thus necessary will create a temporary
QString, which will bind to the returned QStringView, but will already be
destroyed (taking the data QStringView references with it) when control
returns to the caller.

This particular mistake is easy to prevent statically, though:

   QStringView(QString &&) = delete;

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

I guess we need QStringView for QString and QByteArrayView for QByteArray, etc.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Smith Martin <martin.sm...@theqtcompany.com>
Sent: Tuesday, October 20, 2015 9:13 AM
To: Marc Mutz; development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

I see. But then, if I have QStringView, doesn't that eliminate most of the 
reasons for needing the other string containing classes? If I want the 
efficiency of QStringView, won't QString underneath always be the right choice?

In Thiago's example, if I have a QStringView API on my class, would I ever want 
to switch the QString to a QByteArray?

Does using QStringView with QString work as well or better than WByteArray et 
al?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Marc Mutz <marc.m...@kdab.com>
Sent: Monday, October 19, 2015 11:26 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> >This API here simply cannot exist because the returned value would be a
> >dangling reference.
>
> I don't understand. Implicit for using the QStringView data() function is
> knowing that once the QByteArray is set, it is never changed. Then the
> data() function is ok, isn't it?

A QStringView points to QChar* (or ushort*) while a QByteArray only provides
char*. The fromLatin1() (say) call thus necessary will create a temporary
QString, which will bind to the returned QStringView, but will already be
destroyed (taking the data QStringView references with it) when control
returns to the caller.

This particular mistake is easy to prevent statically, though:

   QStringView(QString &&) = delete;

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>Return values must always be QString, never QStringView. Returning a view is
>like returning a reference and goes against Qt's library code policy.

But an assumption is the user manages the ownership of the underlying string, 
so it seems different. I'm rewriting the C++ parsing in qdoc. It calls a 
tokenizer that has a token()function that returns an enum value and a lexeme() 
function that returns a QString. It builds the QString for lexeme() each time, 
when it would be better to return a QStringView, since I know the text won't 
change. For the names that have to be saved, the QStringView can be passed to 
the tree node constructor, and only one QString gets built.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Thiago Macieira 
Sent: Sunday, October 18, 2015 10:55 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> That the proposal is that every single function currently taking a
> QString should instead be changed to take a QStringView instead, unless
> a few exceptional cases (for instance the function is used to store the
> string somehow, plus other cases under discussion). Similar case for
> return values. If that doesn't look like a radical change to you...

Return values must always be QString, never QStringView. Returning a view is
like returning a reference and goes against Qt's library code policy.

--
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>The point I'm trying to make 
>is that returning a non-owning copy means that something else must own the 
>data. That's what goes against the library code policy.

The library code policy is an one that has always made sense in the 
pre-string_view world. But if string_view is being added to C++, don't we have 
to add it to Qt? And if we add it to Qt, don't we have to support it in all the 
Qt classes where it could improve performance? 

Won't internet-of-things developers want a library that fully supports 
string_view?

martin



From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Thiago Macieira <thiago.macie...@intel.com>
Sent: Monday, October 19, 2015 8:21 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

On Monday 19 October 2015 06:10:41 Smith Martin wrote:
> >Return values must always be QString, never QStringView. Returning a view
> >is like returning a reference and goes against Qt's library code policy.
>
> But an assumption is the user manages the ownership of the underlying
> string, so it seems different.

Are you talking about a class that operates on user-provided data?

In that restricted scenario, it might make sense. The point I'm trying to make
is that returning a non-owning copy means that something else must own the
data. That's what goes against the library code policy.

Example:

QUrl url;
QStringView query() const;

It's not possible to write the query() function.

> I'm rewriting the C++ parsing in qdoc. It
> calls a tokenizer that has a token()function that returns an enum value and
> a lexeme() function that returns a QString. It builds the QString for
> lexeme() each time, when it would be better to return a QStringView, since
> I know the text won't change.

Good, but qdoc is not a library so it's not subject to the library code
policy.

> For the names that have to be saved, the
> QStringView can be passed to the tree node constructor, and only one
> QString gets built.

--
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>That's like saying that functions musn't return a QStringRef. But see
>QXmlStreamReader, which uses that to (apparently) good effect.

That's a good point, but the other points you raise are just arguing by finding 
fault with Qt. I think fully supporting QStringView has to be justified by 
showing a way to include it in the library so that it can be used safely.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Marc Mutz 
Sent: Monday, October 19, 2015 11:23 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> > That the proposal is that every single function currently taking a
> > QString should instead be changed to take a QStringView instead, unless
> > a few exceptional cases (for instance the function is used to store the
> > string somehow, plus other cases under discussion). Similar case for
> > return values. If that doesn't look like a radical change to you...
>
> Return values must always be QString, never QStringView. Returning a view
> is  like returning a reference and goes against Qt's library code policy.

That's like saying that functions musn't return a QStringRef. But see
QXmlStreamReader, which uses that to (apparently) good effect.

I also mentioned the case where a plugin returns some static data as a QString
coming from a QStringLiteral. You yourself mentioned that that's going boom
when the plugin is unloaded. If the plugin instead returned a QStringView,
then callers wishing to store the result would have toString() it, making a
deep copy and insulating themselves from the plugin being unloaded, while
users wishing to just do some mix-and-matching with the string could avoid the
copy by keeping the returned data in a QStringView.

People should stop being so afraid of a string deep copy. It's a no-op for
SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
matter for all other strings. Here's where safety and performance could
actually go hand-in-hand for once.

Safety? Yes, the above QStringLiteral problem and also, as you know (and it's
even documented) that Qt doesn't implement CoW correctly:

  QString s1 = "foo";
  QString::iterator it = s1.begin();
  QString s2 = s1;
  *it = 'b';
  // oops: s2 == "boo", too!

I would like to see proof that ref-counted strings are actually worth it, even
in the unsafe Qt implementation, considering that the C++ world slowly moves
away from them.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>Again, please try writing this method:

Doesn't that example just mean there are some classes that can't have a 
QStringView API? A class should have a QStringView API if it can be used safely.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Thiago Macieira 
Sent: Monday, October 19, 2015 5:54 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

On Monday 19 October 2015 11:23:38 Marc Mutz wrote:
> On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> > On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> > > That the proposal is that every single function currently taking a
> > > QString should instead be changed to take a QStringView instead, unless
> > > a few exceptional cases (for instance the function is used to store the
> > > string somehow, plus other cases under discussion). Similar case for
> > > return values. If that doesn't look like a radical change to you...
> >
> > Return values must always be QString, never QStringView. Returning a view
> > is  like returning a reference and goes against Qt's library code policy.
>
> That's like saying that functions musn't return a QStringRef. But see
> QXmlStreamReader, which uses that to (apparently) good effect.

No, it isn't.

First of all, QStringRef keeps a pointer to the original QString, so it isn't
as fragile as QStringView. In fact, during the development of the XML stream
classes, there was a QSubString class that did more or less what QStringView
would do. It got replaced for a reason.

Second, this falls under the exception of parsing a large block of data and
getting information about chunks inside.

And besides, it does make code using those classes uglier.

> I also mentioned the case where a plugin returns some static data as a
> QString coming from a QStringLiteral. You yourself mentioned that that's
> going boom when the plugin is unloaded. If the plugin instead returned a
> QStringView, then callers wishing to store the result would have toString()
> it, making a deep copy and insulating themselves from the plugin being
> unloaded, while users wishing to just do some mix-and-matching with the
> string could avoid the copy by keeping the returned data in a QStringView.

I agree on the advantage.

>From what I can see, a Qt6 QStringView is a QString with a null d pointer,
except that it triggers deep copy everywhere whre it's assigned to a regular
QString. I'm fine with having the class.

I'm not ok with changing the library code policy.

> People should stop being so afraid of a string deep copy. It's a no-op for
> SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
> matter for all other strings. Here's where safety and performance could
> actually go hand-in-hand for once.

That's not what I am afraid of.

Again, please try writing this method:

class Foo
{
QUrl url;
public:
QStringView host() const;
};


--
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>This API here simply cannot exist because the returned value would be a 
>dangling reference.

I don't understand. Implicit for using the QStringView data() function is 
knowing that once the QByteArray is set, it is never changed. Then the data() 
function is ok, isn't it?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Thiago Macieira <thiago.macie...@intel.com>
Sent: Monday, October 19, 2015 9:38 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt  
APIs taking strings

On Monday 19 October 2015 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.

Right. I'm simply saying that "if it can be used safely" is very, very
restricted.

Suppose you have in v1:

class Foo
{
QString m_data;
public:
QStringView data() const;
};

Which looks fine and works without dangling references. Then in v2, you need to
do this:

class Foo
{
QByteArray m_data;
public:
QStringView data() const;
};

This API here simply cannot exist because the returned value would be a
dangling reference.

Therefore, QStringView returns must be treated like references: only in
exceptional cases.

--
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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>If that doesn't look like a radical change to you...

But that's way down the line. 

We can add QStringView and overloads that take QStringView without removing the 
overloads that take QString. 

Then we can deprecate the overloads that take QString.


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Sent: Sunday, October 18, 2015 9:27 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs 
taking strings

Il 18/10/2015 20:30, Smith Martin ha scritto:
> After watching the video on string_view, it seems clear we have to offer a 
> QStringView, so I don't see what is "semi-radical" about your proposal.

That the proposal is that every single function currently taking a
QString should instead be changed to take a QStringView instead, unless
a few exceptional cases (for instance the function is used to store the
string somehow, plus other cases under discussion). Similar case for
return values. If that doesn't look like a radical change to you...

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

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

After watching the video on string_view, it seems clear we have to offer a 
QStringView, so I don't see what is "semi-radical" about your proposal.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Marc Mutz 
Sent: Tuesday, October 13, 2015 10:46 PM
To: development@qt-project.org
Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs   
taking strings

Hi,

After looking quite a bit into the current state of string handling in Qt for
my QtWS talk last week, I have become frustrated by the state of string
handling in Qt.

We have such powerful tools for string handling (QStringRef, QStringBuilder),
but all APIs outside QString and its immediate surroundings only deal in
QString. The correct way would be to overload every function taking QString
with QLatin1String and QStringRef versions, and then, for some other rare
cases, const QChar *, int size. Let alone std::basic_string.

I would therefore like to propose to abandon QString for new API (and over
time phase it out of existing API), and only provide (const QChar*, size_t) as
the most general form. I would propose to package the two into a class, called
- you guessed it - QStringView.

=FAQ=

Q: Why not just use QStringRef?

A: QStringRef is tied to QString. E.g. you can't create a QStringRef from a
pair of QChar*, int. It also is kind of stuck in historic mistakes making it
undesireable as a cheap-to-pass parameter type.

Q: What mistakes do you refer to?

A: The fact that it has copy ctor and assignment operator, so it's not a
trivally-copyable type and thus cannot efficiently passed by-value. It may also
be too large for pass-by-value due to the rather useless QString pointer
(should have been QStringData*, if any). Neither can be fixed before Qt 6.

Q: Why size_t?

A: The intent of QStringView (and std::experimental::string_view) is to act as
an interface between modules written with different compilers and different
flags. A std::string will never be compatible between compilers or even just
different flags, but a simple struct {char*, size_t} will always be, by way of
it's C compatibility.

So the goal is not just to accept QString, QStringRef, and (QChar*,int) (and
QVarLengthArray!) as input to QStringView, but also
std::basic_string and std::vector.

Q: What about the plans to make QString UTF-8-backed?

A: QStringView-using code will need to be ported just as QString-using code
will.

Q: What future do you have in mind for QStringRef?

A: None in particular, though I have found a need for an owning QStringRef in
some places. But I expect Qt 6' QString to be able to provide a restricted
view on shared data, such that it would subsume QStringRef completely.

Q: What about QLatin1String?

A: Once QString is backed by UTF-8, latin-1 ceases to be a special charset. We
might want something like QUsAsciiString, but it would just be a UTF-8 string,
so it could be packed into QStringView.

Q: What about QByteArray, QVector?

A: I'm unsure about QByteArrayView. It might not pull its weight compared to
std::(experimental::)string_view, but I also note that we're currently missing
a QByteArrayRef, so a QBAView might make sense while we wait for the std one
to become available to us.

I'm actively opposed to a QArrayView, because I don't think it provides us
with anything std::(experimental::)array_view doesn't already.

Q: What about a rope?

A: A rope is a more complex string that can provide complex views on existing
data as well as store rules for generating stretches of data (as opposed to
the data itself).

A rope is a very complex data structure and would not work as a universal
interface type. It would be cool if Qt had a rope, but that is outside the
scope of my proposal.

Q: What do you mean when you say "abandon QString"?

A: I mean that functions should not take QStrings as arguments, but
QStringViews. Then users can transparently pass QString, QStringRef and any of
a number of other "string" types without overloading the function on each of
them.

I do not mean to abandon QString, the class. Only QString, the interface type.

Q: What API should QStringView have?

A: Since it's mainly an interface type, it should have implicit conversions
from all kinds of "string" types, but explicit conversion _to_ those string
types. It should carry all the API from QString that can be implemented on
just a (QChar*, size_t) (e.g. trimmed(), left(), mid(), section(), split(),
but not append(), replace() (except maybe the (QChar,QChar) overload.
Corresponding QString/Ref API could (eventually) just forward to the
QStringView one.

Thanks, now fire away,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>I have not discovered anything. I merely use the existing tools and found that 
>APIs outside the core Qt string classes largely ignore them, and probably 
>rightfully so, since there's a combinatorical explosion when you combine 
>QLatin1String, QString, QStringRef, QChar, const char*, QByteArray, etc.

When you use tools as you say you did, to find some knowledge we didn't know 
before, that's what discover means. But now you are changing the meaning again. 
When you started this discussion, I understood you to mean that QString, et al, 
are inefficient in the sense that there is a better way, and the QStringView is 
that better way. But now...

>QStringView is not more efficient than any of those. It is an abstraction over
>them, so that you can use, say, QStringRef in more places.

I understood your last reply to me to mean that we should be using QStringRef 
in more places anyway, whether we add QStringView to the mix or not, and that 
one thing that is clearly missing from Qt documentation is a "How and when to 
use" discussion for all of QString, QLatin1String, QString, QStringRef, QChar, 
const char*, and QByteArray, including which combinations of these classes to 
use and which combinations to avoid.

>Then documenters should ask. There's a class QStringRef. If you/they don't
>understand what the difference is to QString and why it exists, just ask.

Both classes are documented, so we have no reason to think we don't understand 
them. You can argue that the doc team should be using Qt in anger as we go, and 
we should be discovering ourselves how Qt classes should be used to achieve 
optimal efficiency, but we don't have much time for that, given all the 
documentation that has to be written, so we depend on the engineers who design 
and/or use Qt classes to tell us when we need to add this higher level how-to 
knowledge. 

>I try to shake thing up here and
>there, because I'm a C++ fanboy and want Qt to stay relevant.

We all want that. That's why we have begun to improve the docs, at your 
recommendation, with regard to using QVector over QList. This 
QString/QStringView discussion is a similar situation, but with each reply from 
you, I become more confused about what problem you are trying to solve with 
QStringView. You listed most of the Qt string handling classes above. I think 
you are stating or implying that it is a mistake for a user to arbitrarily mix 
them in an application. But this is easy to do. qdoc uses QString everywhere. 
It is after all a string manipulation program.  We have recently improved qdoc 
performance by quite a lot, both by changing its strategy and by improving its 
use of string classes. I am sure there is more to be done, because qdoc mixes 
all the Qt string classes. That's easy to do because in a routine that is 
exclusively QString based, you find you need to call a function that returns a 
QByteArray or that only accepts a parameter that is const char*. 

Is QStringView meant to avoid this by adding APIs to Qt classes that use 
QStringView? Is the goal to include a QStringView API everywhere and then 
always pass around QStringViews instead of combinations of the string handling 
classes?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
<development-bounces+martin.smith=theqtcompany@qt-project.org> on behalf of 
Marc Mutz <marc.m...@kdab.com>
Sent: Saturday, October 17, 2015 10:13 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

On Saturday 17 October 2015 15:51:35 Smith Martin wrote:
> >Please understand my POV: I am of the firm belief that Qt has no business
> >creating inefficiencies for its users by sloppy implementation. Anywhere.
>
> I think you are overreacting here, way too much. You have discovered a more
> efficient way to handle strings, but that doesn't mean Trolltech created
> inefficiency by a sloppy implementation of QString. QString has been used
> productively by many users for a long time. The fact that a moere
> efficient implementation exists doesn't mean the current implementation is
> inefficient.

I have not discovered anything. I merely use the existing tools and found that
APIs outside the core Qt string classes largely ignore them, and probably
rightfully so, since there's a combinatorical explosion when you combine
QLatin1String, QString, QStringRef, QChar, const char*, QByteArray, etc.

QStringView is not more efficient than any of those. It is an abstraction over
them, so that you can use, say, QStringRef in more places.

> >And please don't forget that QString fanboys can continue to massacre the
> >heap if they so wish. After all, we've had QStringRef for a long time
> >now, but most people still write str.mid(n).toInt() instead of
> >str.midRef().toInt().

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

>Please understand my POV: I am of the firm belief that Qt has no business
>creating inefficiencies for its users by sloppy implementation. Anywhere.

I think you are overreacting here, way too much. You have discovered a more 
efficient way to handle strings, but that doesn't mean Trolltech created 
inefficiency by a sloppy implementation of QString. QString has been used 
productively by many users for a long time. The fact that a moere efficient 
implementation exists doesn't mean the current implementation is inefficient. 

>And please don't forget that QString fanboys can continue to massacre the heap
>if they so wish. After all, we've had QStringRef for a long time now, but most
>people still write str.mid(n).toInt() instead of str.midRef().toInt().

But that is because we don't explain in the documentation the most efficient 
ways to use these classes together. And the reason it isn't in the 
documentation is we who write the documentation don't know what you know.

>I find it intolerable that todays software
>takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs
>done in less wallclock time than software 20 years ago.

But the fact is, it usually IS tolerable, because the applications you are 
talking about mostly work in human time.

Your efforts to improve Qt are most appreciated, but you make it sound like we 
should publicly name and shame all the engineers who ever worked on QString but 
who failed to find the holy grail of the most efficient implementation.

I had no idea my heap was in such pain.

martin



From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Marc Mutz 
Sent: Saturday, October 17, 2015 1:18 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

Kurt,

The mail you're replying to has nothing to do with QStringView. It was a
tangent about std::string_view.

If you need a real-world example of where QStringView would be handy: Some
3rd-party code returns you a char16_t *path, and you want to perform a
QDir::cd(). Currently, you need to create a QString (which allocates). Had
QDir::cd() taken a QStringView, you wouldn't have that allocation.

Another example I already mentioned:

> E.g. local QStrings could be replaced by QVarLengthArray,
>
> e.g. in code like this:
> QString joinstr = QLatin1String("\"\n");
> joinstr += indent;
> joinstr += indent;
> joinstr += QLatin1Char('"');
>
> QString rc(QLatin1Char('"'));
> rc += result.join(joinstr);
> rc += QLatin1Char('"');
>
> Even when replaced with QStringBuilder:
> QString joinstr = QLatin1String("\"\n") + indent + indent
>
>+ QLatin1Char('"');
>
> QString rc = QLatin1Char('"') + result.join(joinstr) +
> QLatin1Char('"');
>
> But the main benefit would be that we only ever need one overload for a
> QString-taking function, not N, N > 3.

Final with QStringView (and a minor modification to QStringBuilder):

  QVarLengthArray joinstr // doesn't alloc (for most 'indent's)
  = QLatin1String("\"\n") + indent + indent + QLatin1Char('"');

  // in this line, QStringList::join() doesn't know about QVarLengthArray.
  // but it takes a QStringView and therefore transparently accepts QVLA
  QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"');

Please understand my POV: I am of the firm belief that Qt has no business
creating inefficiencies for its users by sloppy implementation. Anywhere. We
cannot know whether one user is calling QString::multiArg() in a tight loop.
It might be dominating her runtime. 99.9% of users probably couldn't care less
about QString::multiArg() performance. But we need to care about the 0.1%,
because that number is much closer to 100% if you integrate it over all users'
critical paths (iow: every Qt user will have *some* part of Qt that she wished
was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at some
point in the past!).

The inefficiencies I (and Sergio and Milian and, I'm happy to see, Friedemann,
and others) care about are not ones you will find in a profiler in those 99.9%
of cases, because they are not used in a critical path. But even for the 99.9%
of users, if we make all of Qt 10% faster on average, their apps will run
close to 10% faster, too. Automatically.

So yes, I care about performance. I find it intolerable that todays software
takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs
done in less wallclock time than software 20 years ago. And people don't use
C++ because it's pretty. You cannot compete with Java on programmer efficiency.
Its standard library is orders of magnitude larger than C++'s. People choose
C++ (and accept the associated loss in programmer efficiency), because they
require the bare metal 

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Smith Martin]

Then after we add QStringView, we will have QString for containing a string and 
QStringView for passing its contents out of Qt?

martin


From: m...@kdab.com <m...@kdab.com> on behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Friday, October 16, 2015 10:07 AM
To: Smith Martin
Cc: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in  Qt   
APIs taking strings

On Friday 16 October 2015 07:59:40 Smith Martin wrote:
> Can you refocus the discussion for everyone? For me at least?
>
> QString is my favorite class of all time. I use it every day in every
> program; it always works, and I never make a mistake.

Then you can continue to be blissfully ignorant of reality as you are :) If
you are a QString fanboy and don't care about 3rd-party code and/or efficiency,
then you can just continue as before.

> 1. What is the problem with QString that QStringView will solve?

TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within
pure Qt-code and in particular when interfacing with 3rd-party code, BiC
issues,

> 2. Why can't QString be fixed?

Because it is a container, not an interface type.

An interface type needs to be BC across most of compilers and languages (incl.
C and - potentially Java).

A container needs to handle (as in own) memory. An interface type (quite
obviously, if it's to work with C, too) cannot.

> 3. What is a string view?

A pimped { QChar *begin, QChar *end; }

Thanks,
Marc

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

Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum values

[Smith Martin]

But it has actually been used to deprecate single enum values. Here is an 
example from QTextFormat:

class Q_GUI_EXPORT QTextFormat
{
Q_GADGET
public:
enum FormatType {
InvalidFormat = -1,
BlockFormat = 1,
CharFormat = 2,
ListFormat = 3,
#if QT_DEPRECATED_SINCE(5, 3)
TableFormat = 4,
#endif
FrameFormat = 5,

UserFormat = 100
};
 
.cpp
/*!
\enum QTextFormat::FormatType

This enum describes the text item a QTextFormat object is formatting.

\value InvalidFormat An invalid format as created by the default
 constructor
\value BlockFormat The object formats a text block
\value CharFormat The object formats a single character
\value ListFormat The object formats a list
\omitvalue TableFormat Unused Value, a table's FormatType is FrameFormat.
\value FrameFormat The object formats a frame

\value UserFormat

\sa QTextCharFormat, QTextBlockFormat, QTextListFormat,
QTextTableFormat, type()
*/

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Thiago Macieira thiago.macie...@intel.com
Sent: Wednesday, August 12, 2015 11:06 PM
To: development@qt-project.org
Subject: Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum  
values

On Wednesday 12 August 2015 22:12:43 Denis Shienkov wrote:
 So, my question is: how to deprecate the specific enum value with a
 right way for all compilers/platforms?

Don't do it. There's no portable way yet. Maybe in a year or two we can
introduce a macro for 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QNoDebug - available but undocumented

[Smith Martin]

qdebug.cpp should contain a comment like this:

/*!
  \class QNoDebug
  \internal
*/


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Olivier Goffart oliv...@woboq.com
Sent: Thursday, July 30, 2015 2:36 PM
To: development@qt-project.org
Subject: Re: [Development] QNoDebug - available but undocumented

On Thursday 30. July 2015 13:33:28 Tomasz Siekierda wrote:
 Hi,

 just a quick observation: QNoDebug class can be used in code (compiles,
 works fine), but there is no documentation for it.

 Is that intentional? Shouldn't it be either hidden (made private) or
 documented? Although I have just learned about it's existence by accident,
 it looks like it can be quite useful, so I vote for adding some docs.

It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is defined.
That way the code compiles but is optimized away.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

I guess we could add some output to your container benchmark app that explains 
what your QListT will actually do and not do.

martin 


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Monday, July 27, 2015 11:16 AM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Monday 27 July 2015 00:27:18 Kevin Kofler wrote:
 It doesn't switch the stuff it actually guarantees:

That sentence is perfectly correct.

But here's the catch: The docs guarantee _a certain implementation_, incl. the
switching. The problem is that the conditions under which the switch occurs
are quite hard for non-experts to check.

This is the beauty of the STL: without mentioning the actual implementation
anywhere, its containers have such tailor-made guarantees that effectively only
one implementation possibility is left (they even rule out CoW without
mentioning it!).

But since the STL doesn't specify any implementation, if research finds a data
structure that meets those guarantees, the new structure automatically becomes
permissible.

This is what made std::make_shared's optimisation possible, e.g.

Qt containers are not like that. QList docs say exactly how it's implemented,
but not exactly what it guarantees. Thus, coming to depend on details of the
implementation is a perfectly reasonable thing to do for a developer. It's
documented, after all, if only indirectly.

Quite some code in QtBase alone already depends on the de-facto guarantee of
stable references, among them, just off the top of my head:

- QDataWidgetMapper
- QToolBox
- one of the lists in QMime*
- QListQMakeLocalFileName in qmake

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Let’s at least fix the docs. It won’t keep people from
choosing QList because the type is so pervasive in Qt’s API, but at least
we’re then giving better advice.

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

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Knoll Lars lars.kn...@theqtcompany.com
Sent: Monday, July 20, 2015 4:53 PM
To: Giuseppe D'Angelo; development@qt-project.org
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList, 
use Q_DECLARE_TYPEINFO

On 13/07/15 10:34, Giuseppe D'Angelo giuseppe.dang...@kdab.com wrote:

Il 12/07/2015 23:19, Alejandro Exojo ha scritto:
 El Sunday 12 July 2015, Thiago Macieira escribió:
 On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
 I can see by your explanation that QVector is almost always more
 efficient than QList. But sometimes the difference doesn't matter.

 If it doesn't, then why not choose QVector?

 I've carefully read the thread, and I think the issue Martin or others
might
 have is:

 * Documentation and the common know how about Qt containers tells that
QList
 is a reasonable middle ground choice (sometimes is like a vector,
sometimes
 like a linked list/vector hybrid). Is what the docs say, what the Qt
Quarterly
 article says (which is old, but Olivier gave a recent explanation on
 containers on 2012's devdays), what is being used in the API as return
type,
 etc.

Nitpicking: it's never like a linked list. It's either an array of T or
an array of T*. Access is always O(1) (with potentially a big factor
hidden due to the indirection), insertion in the middle always O(N)
(with potentially a smaller factor than QVector, esp. for big Ts, due to
the indirection), etc.

Then, yes, QList is the recommended generic sequential container, and
the one used all around in Qt APIs. And that's the problem which started
this discussion.

Yes, I think pretty much everybody agrees that QList does not work as
advertised. In the ideal case it’s performance is about as good as a
QVector, in most other cases (with a few exceptions) it’s a lot worse. So
Marc is completely right that we should be using QVector by default in any
new code and in our implementations (as long as we don’t need QList
compatibility with existing API).

Most likely, we should change QList in Qt 6 to simply share it’s
implementation with QVector and make them both compatible, but we
unfortunately can’t do this right now.


 * Marc has been criticizing what the docs says, but even being a
significant
 contributor to Qt, did not propose to change that.

And I actually disagree with that, given that QVector is faster than
QList in the majority of the cases (and std::vector could be even faster
and/or expand to less code). Having false statements in the docs is not
good. I would like to see them changed.

Yes, we can’t complain about people using Qt wrongly (and even our own
developers and contributors), if our docs are wrong. Let’s fix them to say
that you should use QVector if possible and not QList.

 * According to Martin's explanations, he did send a patch for qdoc that
 replaced a wrong choice of container, but the change did not have any
apparent
 effect.

Which has been pointed out to be irrelevant to the purposes of this
discussion (I have no idea of qdoc internals, has anyone profiled it?
Maybe 99% of the time is spent on I/O or parsing C++ files and QVector
over QList gives an advantage in nanoseconds for that particular use
case?).

But the totality of the other points in the first message stay, and
noone has so far challenged them...

 * We are having a large thread with a heated discussion, and Marc said
things
 like and the resulting code will be highly fragile and/or extremely
 inefficient. People might felt a bit offended by that. Is something
being
 said about their work, after all.

Please do not make this an ad-hominem. It's an argument about the code.

When you spot an unwarranted usage of a QList in some code, what it is
about? Pick:

A) Premature pessimization (you could've used QVector instead, but you
picked QList because it's the default container -- it's documented
that way!)

B) You want amortized fast prepend

C) Your type is bad and you want to rely on validity of references
when the container gets modified

(There's no I want to call a function taking a QList because that's
totally justified).

Experience tells that you're in A) 99% of the time (extremely
inefficient). B) or C) count for highly fragile, because you may
break the code (or make it way more inefficient) by refactoring it.
We've had cases of that. IIRC, this was a case of C) (refactoring from
QList to QVector):


https://codereview.qt-project.org/#/c/10878/9/src/corelib/kernel/qcoreapp
lication.cpp


 To summarize:

 I not sure whether you (plural) think that no container should be
advised as
 the preferred one, or if it should

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

I'm trying to get information for updating the documentation for QList. At the 
moment, it is misleading, judging by what you are saying. Maintaining the 
documentation isn't a red herring. It's actually my job.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Sunday, July 12, 2015 2:03 AM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Saturday 11 July 2015 21:50:05 Smith Martin wrote:
 Suppose (as in the use case that started this thread) that your
 QList/QVector/QLinkedList will only have a small number of elements in it.
 Almost always less than 5. Never more than about 8. Does this change the
 analysis at all? In particular, does it minimize the performance
 differences?

 And suppose the use case also assumes that you add all the elements to the
 container immediately and then you process the container sequentially
 immediately after that. So there is no inserting, no searching, and no
 other mallocs.

If you have only a very small number of elements, you should either be using a
QVarLengthArray to avoid _any_ container-related heap allocations, or else a
std::vector, because the overhead of the d-pointer is relatively-speaking a
lot higher at small element counts.

And please stop chasing red herrings. It was _not_ the use of
QListParsedSomething in qdoc that originated this thread. Look at my Gerrit
list of changes, merged and open. And my blog post is five years old.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

+1
martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Andreas Aardal Hanssen andr...@hanssen.name
Sent: Sunday, July 12, 2015 4:29 PM
To: development@qt-project.org
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList,   
use Q_DECLARE_TYPEINFO

 On 12 Jul 2015, at 16:58, Marc Mutz marc.m...@kdab.com wrote:
 That's because your benchmark runs entirely in L1.
 If you want to test containers of 10, 100, 1000 and 1 elements each, then
 make
 - one run over 1×N containers of 1 elements each,
 - one run over 10×N containers of 1000 elements each,
 - one run over 100×N containers of 100 elements each,
 - one run over 1000×N containers of 10 elements each.

This is getting defensive, and quite frankly, a bit boring. The fact that half 
of the emails are from one author defending his absolute view with increasingly 
complex arguments suggests action points be taken and the debate be closed.

Clearly Marc should write a /book/ about which tricks should be applied when 
writing high performance code. It’s non-trivial, and it really is no 
container’s role to be the sole solution to everything. There’s also no such 
book out there but clearly many “undocumented tricks” and pitfalls.

We can’t add tables, and complex explanations, or dynamic forms where you input 
your sizes and types, to Qt docs to “help” people choose the right container. 
Complex docs == bad docs. Writing high performance code requires a touch of 
genius, and only needs to be applied to choice of algorithms at the highest 
level and only the most important loops at the lowest level. The performance of 
QList isn’t the prime focus of people writing normal code. Paint engine 
insides, for example, we make an effort not to allocate memory at all from 
begin to end. That sort of rules out most container classes out there.

Suggested actions points:

1. Update Qt docs to indicate that careful planning, perhaps a pointer to 
Marc’s blog, this thread, and QVector docs, could be useful when writing 
performance critical code. I’m certain QList will be just a tiny chapter in 
Marc’s upcoming book but link to that chapter.

2. Analyze (again) when is the time to make Qt’s containers simple wrappers 
over those of stl and/or boost. Performance differences over equivalent classes 
with different APIs should be limited to the API differences themselves. 
Nothing else makes sense.

3. Marc, consider writing that book. It’s not a general book on Qt, because Qt 
is about writing code simple quick and easy with acceptable performance, not 
how to squeeze every cycle out of every part of your code.

Andreas
___
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] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

I expect you to view those videos and to read those articles and then I expect
you to apologise for this mail of yours.

Well qdoc was taking about 15 minutes to run on Qt5, so I followed Andreas' 
advice and changed the high-level algorithm. Now it runs in about 2 minutes. 

I suspect that swapping a QList for a QVector, where the QList is completely 
built all at once with usually only 2 or 3 elements and then traversed and 
destroyed all in the same function, won't reduce that 2 minutes by much. And we 
only run qdoc to rebuild the documentation.

I think this software engineering profession attracts obsessive-compulsive type 
thinkers (AKA perfectionists), because building a software system from a proper 
functional requirements list (written or mental) makes achieving perfection 
possible. Passing all the requirements tests is perfection by definition.

But the obsessive-compulsive type thinker (I am one myself) can become a bit of 
a pain sometimes. striving to better, oft we mar what's well  -- Kink Lear

I like QList. 

martin 



From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Sunday, July 12, 2015 6:18 PM
To: development@qt-project.org
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList,   
use Q_DECLARE_TYPEINFO

On Sunday 12 July 2015 16:29:58 Andreas Aardal Hanssen wrote:
  On 12 Jul 2015, at 16:58, Marc Mutz marc.m...@kdab.com wrote:
  That's because your benchmark runs entirely in L1.
  If you want to test containers of 10, 100, 1000 and 1 elements each,
  then make
  - one run over 1×N containers of 1 elements each,
  - one run over 10×N containers of 1000 elements each,
  - one run over 100×N containers of 100 elements each,
  - one run over 1000×N containers of 10 elements each.

 This is getting defensive, and quite frankly, a bit boring. The fact that
 half of the emails are from one author defending his absolute view with
 increasingly complex arguments suggests action points be taken and the
 debate be closed.

ROTFL. You made my day. Martin asks increasingly narrowly.focused questions,
and you make that into me being defensive. Yeah, right.

Obviously, I beg to differ. It's not *my* view. It's just not *your* view:

- Scott Meyers: https://www.youtube.com/watch?v=WDIkqP4JbkE
- Chandler Carruth: https://www.youtube.com/watch?v=fHNmRkzxHWs
- Herb Sutter: https://www.youtube.com/watch?v=L7zSU9HI-6I
- Alex Stepanov  Bjarne Stroustup:
http://www.stepanovpapers.com/container_benchmark.cpp
- Ulrich Drepper: http://www.akkadia.org/drepper/cpumemory.pdf

Clearly, all of the above (and Thiago, and Peppe, and Milian) are all wrong
and I am part of a big conspiracy.

 Clearly Marc should write a /book/ about which tricks should be applied
 when writing high performance code.

Those books have already been written. You should read them!

- Herb Sutter: Exception C++, More Exceptional C++, C++ Coding Standards
- Scott Meyers: Effective C++, More Effective C++, Effective STL, Effective
Modern C++
- ...

I expect you to view those videos and to read those articles and then I expect
you to apologise for this mail of yours.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Marc, I think you misunderstand the nature of the discussion. I don't think 
anyone disputes your analysis of the relative efficiencies of the various 
collections. I think you are dismissing the simple elegance of QList for 
getting a Qt application up and running quickly. Or, as in my use case, making 
a change quickly to correct a bug. 

I can see by your explanation that QVector is almost always more efficient than 
QList. But sometimes the difference doesn't matter.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Sunday, July 12, 2015 7:14 PM
To: development@qt-project.org
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList,   
use Q_DECLARE_TYPEINFO

On Sunday 12 July 2015 17:34:25 Smith Martin wrote:
 I like QList.

This level of discussion, combined with a complete unwillingness to look
anything up that was linked to in this thread is why I don't try patch the Qt
docs.

And I'm sorry for not having stuck to my initial resolve not to talk about
_why_ QList is bad. All the information is out there, and I won't convince
anyone who's TL;DR;

Hereby reinstated.

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

If it doesn't, then why not choose QVector?

My intent in getting the information from Marc is to change the documentation 
of QList to say that.

But QList is easy to use. 

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Thiago Macieira thiago.macie...@intel.com
Sent: Sunday, July 12, 2015 7:45 PM
To: development@qt-project.org
Subject: Re: [Development] Container benchmark was HEADS UP: Don't use QList,   
use Q_DECLARE_TYPEINFO

On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
 I can see by your explanation that QVector is almost always more efficient
 than QList. But sometimes the difference doesn't matter.

If it doesn't, then why not choose QVector?
--
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Suppose (as in the use case that started this thread) that your 
QList/QVector/QLinkedList will only have a small number of elements in it. 
Almost always less than 5. Never more than about 8. Does this change the 
analysis at all? In particular, does it minimize the performance differences?

And suppose the use case also assumes that you add all the elements to the 
container immediately and then you process the container sequentially 
immediately after that. So there is no inserting, no searching, and no other 
mallocs.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Saturday, July 11, 2015 10:27 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Saturday 11 July 2015 19:25:20 Thiago Macieira wrote:
 But Qt Creator was SO SLOW I noticed this when I tried to compile Qt
 and  moc was horribly slow too.

Does QList still use a linear growth strategy instead of a geometric one? Same
problem, just less so. Technically still O(N²) behaviour.

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Do you mean that if I declare this:

typedef QListParsedParameter ParsedParameterList;

where ParsedParameter is:

struct ParsedParameter {
bool qPrivateSignal_;
QString dataType_;
QString name_;
QString defaultValue_;
  ParsedParameter() : qPrivateSignal_(false) { }
};

...it will create each list entry as a QListParsedParameter* even though I 
told it not to do that?

martin


From: giuseppe.dang...@kdab.com giuseppe.dang...@kdab.com on behalf of 
Giuseppe D'Angelo giuseppe.dang...@kdab.com
Sent: Friday, July 10, 2015 12:05 PM
To: Smith Martin; development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Il 10/07/2015 11:54, Smith Martin ha scritto:
 Then I don't see why it is so inherently inefficient. The QList entry is 
 allocated on the heap anyway. Doesn't QListC just allocate a bigger entry? 
 And if I don't have the C object stored anywhere else, it has to be 
 somewhere, so why not keep it in the QList entry?

Because for a wrong type C (*) QList will allocate an array of
pointers to C (not an array of Cs!), then proceed to allocate on the
heap every single C object you put in it (by new'ing them); the array
will then store the pointer to the allocated object.

In other words:

struct C {};
QListC list;
for (auto i = 0; i  100; ++i)
list  C{};

Calls operator new at least 101 times.

(*) not movable, or bigger than a void*. And user-defined types are not
movable by default (they're complex). And if we forget
Q_DECLARE_TYPEINFO on public types, we can't add it back because it's
binary incompatible.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

1) you put pressure on the memory allocator, by asking it to allocate on
the heap each individual C object you put in the list. Every single
allocation has a cost, plus the overhead you need for bookkeeping, plus
the costs of getting your memory fragmented, etc.;

This pressure on the memory allocator, what is that? My memory doesn't get 
fragmented, because I only build lists; I never destroy them. But I do have to 
put each C somewhere, and if I use QVectorC, doesn't it allocate a lot of 
them up front? I don't know how many i will need, but the number is usually 0, 
1, or 2 -- the number of parameters in a function signature.

2) you make the compiler produce more inefficient code by introducing
the layer of indirection;

But it will process the list one time only, from beginning to end.

3) you kill caching, as potentially every single access will result in a
cache miss (even in the common scenario of a simple forward iteration
over your list);

Why? All the entries in the list are created at the same time (well, during the 
parsing of the function signature)

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Giuseppe D'Angelo giuseppe.dang...@kdab.com
Sent: Friday, July 10, 2015 1:26 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Il 10/07/2015 13:21, Smith Martin ha scritto:
 But I'm still not clear on one point. If I use QListC, and it is 
 implemented as QListC* because my C is not a good C, why is this 
 inefficent if the only copy of each C is the one that gets allocated on the 
 heap? I just create the list to store things. It won't ever be moved. I will 
 just process the list when it's time comes.

 Why is that inefficient?

Because

1) you put pressure on the memory allocator, by asking it to allocate on
the heap each individual C object you put in the list. Every single
allocation has a cost, plus the overhead you need for bookkeeping, plus
the costs of getting your memory fragmented, etc.;

2) you make the compiler produce more inefficient code by introducing
the layer of indirection;

3) you kill caching, as potentially every single access will result in a
cache miss (even in the common scenario of a simple forward iteration
over your list);

and so on.

Cheers,

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

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

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Calling malloc/free is not a cheap operation, when you profile most Qt
applications, you'll find these functions nearly always in the top 10, often
even the top 5, of functions where most time is spent.

But, Marc made QVector for QList swap in qdoc several weeks ago for the same 
kind of thing, but I couldn't see any difference in the run time for qdoc.

Huh?! I really don't follow your reasoning to both of these points here. I
suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
and similar talks out there to educate yourself? Whenever you access/traverse
a list of pointers, you'll incur cache misses, except in the rare case where
you are lucky and the pointers point to contiguous memory locations. And even
then, you'd have an indirection that Peppe mentions.

In this case, qdoc creates a QListParsedParameter as it parses a function 
signature. All the calls to malloc occur one right after another, and then the 
list is complete. There hasn't been any intervening heap work, so all these 
ParsedParameters will be sequential and will be allocated right after the QList 
itself.

But more importantly, this was just a temporary mechanism to correct the 
parsing of friend function declarations, which broke in qdoc, because good old 
Marc started making friend functions be friend inline functions with the body 
defined in the friend inline declaration inside the class. I think Marc's goal 
is to be the first ever software engineer to use every possible combination of 
C++ features. Still, this one is certainly legal, but qdoc couldn't handle it 
(qdoc still doesn't have a real C++ parser *** see below***), so I rewrote the 
function that parses function declarations so that it waits to create the list 
of parameters until it knows whether it should create the function node in the 
first place.

This QListParsedParameter was meant to be a temporary solution, because that 
list gets copied into a QListParameter if qdoc finally decides to create the 
function node. That, of course, is inefficient, but I generally don'[[t try to 
optimize until I have a working model.

*** If anyone wants to explain how I can use the Creator clang C++ parser in 
qdoc, I could get started on that upgrade to qdoc. It's a big job I don't want 
to start until I know it makes sense.

martin




From: milian on behalf of Milian Wolff milian.wo...@kdab.com
Sent: Friday, July 10, 2015 2:04 PM
To: development@qt-project.org
Cc: Smith Martin; Giuseppe D'Angelo
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 11:35:34 Smith Martin wrote:
 1) you put pressure on the memory allocator, by asking it to allocate on
 the heap each individual C object you put in the list. Every single
 allocation has a cost, plus the overhead you need for bookkeeping, plus
 the costs of getting your memory fragmented, etc.;

 This pressure on the memory allocator, what is that? My memory doesn't get
 fragmented, because I only build lists; I never destroy them. But I do have
 to put each C somewhere, and if I use QVectorC, doesn't it allocate a lot
 of them up front? I don't know how many i will need, but the number is
 usually 0, 1, or 2 -- the number of parameters in a function signature.

Calling malloc/free is not a cheap operation, when you profile most Qt
applications, you'll find these functions nearly always in the top 10, often
even the top 5, of functions where most time is spent.

 2) you make the compiler produce more inefficient code by introducing
 the layer of indirection;

 But it will process the list one time only, from beginning to end.

 3) you kill caching, as potentially every single access will result in a
 cache miss (even in the common scenario of a simple forward iteration
 over your list);

 Why? All the entries in the list are created at the same time (well, during
 the parsing of the function signature)

Huh?! I really don't follow your reasoning to both of these points here. I
suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
 and similar talks out there to educate yourself? Whenever you access/traverse
a list of pointers, you'll incur cache misses, except in the rare case where
you are lucky and the pointers point to contiguous memory locations. And even
then, you'd have an indirection that Peppe mentions.

Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Maybe it's just me, but I'm still not understanding your explanation, and I 
don't think you are answering my question:

I have a struct C which is bigger than a pointer. I declare QListC. Does your 
explanation mean that sometimes (most of the time, in fact), the list will 
become an array of C* instead of an array of C?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 1:34 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 13:29:30 Marc Mutz wrote:
 On Friday 10 July 2015 12:18:04 Smith Martin wrote:
  ...it will create each list entry as a QListParsedParameter* even
  though I told it not to do that?

 Yes. But you told it to do that. You used a _list_.

Ok, I take the bait:

QList is primarily a list, not an array (thus the name). That means that, by
default, references to elements in the list are never invalidated until the
element is removed again. The problem started when someone optimised QList to
contain the elements in an array, but only for *some* types. So, depending on
the type and the QTypeInfo for that flag, QList is either like a std::list or
like a std::vector (QLinkedList / QVector in Qt speak). And it takes great
mental discipline to use it in the proper way, and the resulting code will be
highly fragile and/or extremely inefficient.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

Can we please avoid turning this thread into why is QList bad?

Sorry, you're the one who said it's bad; I'm quite happy with it. I'm asking if 
QListC becomes QListC* even if I declare it as QListC.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 1:25 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 11:54:16 Smith Martin wrote:
 Then I don't see why it is so inherently inefficient. The QList entry is
 allocated on the heap anyway. Doesn't QListC just allocate a bigger
 entry? And if I don't have the C object stored anywhere else, it has to be
 somewhere, so why not keep it in the QList entry?

Can we please avoid turning this thread into why is QList bad?

QList *is* bad. If you don't believe, read
http://marcmutz.wordpress.com/effective-qt/ If you then _still_ don't believe,
do your own benchmarks. Then you will believe.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

I think the impedance mismatch here is that you use list to mean the same
thing as array or vector (in STL terms, not mathematically) while I only
use it to mean linked list, in accordance with the STL.

I actually just mean it's a list, and I don't care how it is implemented. I can 
see that it makes a difference how it is implemented, depending on how it is 
used, but if the use is simply: 1) build the list once; 2) process the list 
once, and every time I add an element to the list I have to create it 
somewhere, I don't see why creating it on the heap is inefficient.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 2:24 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 12:32:45 Smith Martin wrote:
 Maybe it's just me, but I'm still not understanding your explanation, and I
 don't think you are answering my question:

I think the impedance mismatch here is that you use list to mean the same
thing as array or vector (in STL terms, not mathematically) while I only
use it to mean linked list, in accordance with the STL.

That just goes to show how bad of an influence QList has. But it never hid its
design, and, indeed, the default container in Qt 3 was QValueList, which
actually *was* a doubly-linked list. Why Qt always nominates a list as the
default container while the STL recommends std::vector is one of the mysteries
to which only Trolls know the answer :)

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

You are talking about a specific code path in qdoc, while this thread is about
QList in general. This does not help at all.

But that was the point. The argument is that QListC should not be used at 
all, but in the specific code path where it is being changed, it was ok.

And apparently QVector has the same API as QList now, so why don't we deprecate 
QList. Let it always create a QVector.

martin



From: milian on behalf of Milian Wolff milian.wo...@kdab.com
Sent: Friday, July 10, 2015 3:22 PM
To: Smith Martin
Cc: development@qt-project.org; Giuseppe D'Angelo
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 12:48:26 Smith Martin wrote:
 Calling malloc/free is not a cheap operation, when you profile most Qt
 applications, you'll find these functions nearly always in the top 10,
 often even the top 5, of functions where most time is spent.

 But, Marc made QVector for QList swap in qdoc several weeks ago for the same
 kind of thing, but I couldn't see any difference in the run time for qdoc.

Try perf stat, but even then maybe the impact is not high. But if we'd do it
everywhere, the overall performance goes up. Bad performance is often a death
by a thousand cuts.

 Huh?! I really don't follow your reasoning to both of these points here. I
 suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
 and similar talks out there to educate yourself? Whenever you
 access/traverse a list of pointers, you'll incur cache misses, except in
 the rare case where you are lucky and the pointers point to contiguous
 memory locations. And even then, you'd have an indirection that Peppe
 mentions.

 In this case, qdoc creates a QListParsedParameter as it parses a function
 signature. All the calls to malloc occur one right after another, and then
 the list is complete. There hasn't been any intervening heap work, so all
 these ParsedParameters will be sequential and will be allocated right after
 the QList itself.

This is not necessarily true. Malloc implementations are free to return random
pointers. Maybe you are lucky and the stuff is sequential, most probably not.
And you'd still have the indirection. Also, maybe it's not a big deal for this
one specific use case, but in the general usecase you have other allocations
inbetween the list appends, thereby rendering your above reasoning invalid.

 But more importantly, this was just a temporary mechanism to correct the
 parsing of friend function declarations, which broke in qdoc, because good
 old Marc started making friend functions be friend inline functions with
 the body defined in the friend inline declaration inside the class. I think
 Marc's goal is to be the first ever software engineer to use every possible
 combination of C++ features. Still, this one is certainly legal, but qdoc
 couldn't handle it (qdoc still doesn't have a real C++ parser *** see
 below***), so I rewrote the function that parses function declarations so
 that it waits to create the list of parameters until it knows whether it
 should create the function node in the first place.

 This QListParsedParameter was meant to be a temporary solution, because
 that list gets copied into a QListParameter if qdoc finally decides to
 create the function node. That, of course, is inefficient, but I generally
 don'[[t try to optimize until I have a working model.

You are talking about a specific code path in qdoc, while this thread is about
QList in general. This does not help at all.

Bye

  2) you make the compiler produce more inefficient code by introducing
  the layer of indirection;
 
  But it will process the list one time only, from beginning to end.
 
  3) you kill caching, as potentially every single access will result in a
  cache miss (even in the common scenario of a simple forward iteration
  over your list);
 
  Why? All the entries in the list are created at the same time (well,
  during
  the parsing of the function signature)

 Huh?! I really don't follow your reasoning to both of these points here. I
 suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
  and similar talks out there to educate yourself? Whenever you
 access/traverse a list of pointers, you'll incur cache misses, except in
 the rare case where you are lucky and the pointers point to contiguous
 memory locations. And even then, you'd have an indirection that Peppe
 mentions.

 Bye
 --
 Milian Wolff | milian.wo...@kdab.com | Software Engineer
 KDAB (Deutschland) GmbHCo KG, a KDAB Group company
 Tel: +49-30-521325470
 KDAB - The Qt Experts

--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Smith Martin]

This is not premature optimisation. 

It is premature because the entire structure will be removed.


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 5:32 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 14:48:26 Smith Martin wrote:
 but I generally don'[[t try to optimize until I have a working model.

This is not premature optimisation. This is avoiding premature pessimisation
(google it!).

QVector has exactly the same API these days as QList (except that QVector
requires a default ctor and QList doesn't; if something else is missing,
shout), so code using QVector is equally readable as code using QList. If that
is the case, the more efficient alternative is what should naturally flow out
of your fingers.

And another thing: By using a QVector, not only do you avoid an additional
heap allocation per element inserted, you also avoid readers of your code
guessing whether you're using the QList for its list features (like the
QListPage in QToolBoxPrivate - go, read it, it's subtle!) or just as a
container.

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Qt Namespaces (was: RE: Some Qt3D feedback)

[Smith Martin]

Why not leave current Qt modules as they are, without namespaces and with the Q 
prefix on classes, and just introduce the option of adding a new module to Qt 
by putting it in a namespace named QtFoo without the Q prefix on class names, 
or adding it with no namespace and with the Q prefix on classes.

Converting existing modules to use namespaces seems like a lot of aggravation 
for not much gain.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Koehne Kai kai.koe...@theqtcompany.com
Sent: Thursday, June 18, 2015 2:49 PM
To: Marc Mutz; development@qt-project.org
Subject: [Development] Qt  Namespaces (was: RE:  Some Qt3D feedback)

 -Original Message-
 From: development-bounces+kai.koehne=theqtcompany.com@qt-
 project.org [mailto:development-
 bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
 Marc Mutz
 Sent: Thursday, June 18, 2015 3:08 PM
 To: development@qt-project.org
 Subject: Re: [Development] Some Qt3D feedback

 On Thursday 18 June 2015 12:51:01 Smith Martin wrote:
  Do you also advocate rules for using namespaces in Qt? What rules does
  KDE use?

 I believe it's worth reading Sze Howe Koh's mails in this thread and the last
 one (Oct 2013), even if the mails tend to be overwhelmingly full of
 information :)

 On a completely personal note, I'd find the following most natural:

 1. Each Qt Module Qt Foo (name used in docs), with soname
QtMajorVersionFoo, only exports symbols in namespace QtFoo,
potentially with nested inline namespace VMajorVersion.

This has the advantage of being a very simple, mechanical rule. But it's also
very burdensome ... You'll probably end up writing

using namespace QtCore;

in every single source file, since you almost certainly don't want to use
QtCore::QString all over the place.

Now you could argue that QtCore is special, but then again the module contains
something like QState, which is such a generic name that you probably want
to have it in a namespace.

 2. Free functions are not prefixed with 'q' (QtFoo::escape(), not
QtFoo::qEscape()).
 3. Classes, I'm not so sure about the Q. Could leave it for better SC /
branding, or only add a deprecated typedef Bar QBar (either insider the
namespace or outside) for easier porting.

If there's one way to break almost every single line of Qt code out there, it's
removing the 'Q'. Even if you mitigate this by typedef',s I just don't see that
happening ...

So you end up with QQml::QQmlEngine. I like Q's , but that's a tad too much
for my taste.

 4. Includes:
a. QtFoo includes the whole module (as is the case for QtCore, ... now)
b. There's no QtLike include for just the namespace (with enums, free
   functions, etc). To get the namespace, users include any class from the
   module (much like no-one is using QtGlobal atm, but relies on any
   QFoo to include it indirectly).
c. Class includes: QtFoo/QClass or /Class, depending on (3). Maybe
   QClass for backwards-compatibility, with a warning a la strstream on
   GCC.
 5. (most important) don't express a bias for QtFoo::Class vs. using directives
in the docs. That's _entirely_ up to the user. I'd even go so far as to
leave that up to the individual developer in Qt implementations, while
still demanding to following the style found in the file-under-edit, of
course. In docs and examples, I'd tend to use fully-qualified names, if
only for automatic qdoc linking, but if qdoc can cope (doxgen can), I'd use
using directives in the examples/ subdir, at least.

Yeah well, not sure whether that's most important, but I actually agree: 
Namespaces
in general are well understood, and we don't have to patronize our users about 
their
exact use. They will make up their own minds, anyway.



My 2 cents: Adding namespaces carefully where they make sense is a good thing
in the long run, and Qt 6 _might_ be a time where we could also touch existing
modules to avoid clashes. But let's not overdo it. And renaming existing 
popular classes
is IMO a non-starter.

Regards

Kai
___
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] Some Qt3D feedback

[Smith Martin]

Do you also advocate rules for using namespaces in Qt? What rules does KDE use?

From following this thread, the rules that seem natural to me would be:

1. For a new module, either put everything in a namespace or don't use a 
namespace at all.
2. If you put everything in a namespace:
2.1 The name of the namespace should begin with Qt, e.g. Qt3D.
2.2 The classes in the namespace should not be prefixed with Q.
3. In the documentation for the namespace, recommend that, for readability, 
users should not use using.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Thursday, June 18, 2015 1:32 PM
To: development@qt-project.org
Subject: Re: [Development] Some Qt3D feedback

On Thursday 18 June 2015 11:37:48 Knoll Lars wrote:
 Curiously, you didn't list any pro-namespace arguments. I don't know what
 to  make of this, but I fear that a decision is being made based solely
 on arguments from one side.

 So what are the arguments from your point of view then? Apart from
 namespaces being in fashion.

If this was about fashion, then namespaces have been fashionable since at
least the early 2000s (std::, boost::).

Pro namespaces:

- It's the standard way of partioning the name space. C++ users understand it,
  the C++ language understands it, and the C++ compiler does, too.

- namespaces act as an ADL barrier (did you ever got lost in the error
  compilers spew out when you get a simple == wrong? they rival template error
  messages, and the reson is that they're all put into the global scope).

- related: they provide a module-wide C++ scope (std::rel_ops example)

- you cannot (meaningfully) use inline namespaces for versioning (an option we
  should at least consider) if you don't have a namespace in which to put
  them.

- the user has the option of whether she wants to be explicit or convenient.
  Qt trying to impose this decision on its users by name prefixing is
  a) ignoring the fact that many users I know (QtC, KDE(pim)[1], to name the
 biggest and most well-known), liberally use using-directives and do just
 fine. The standard books teach this, too.
  b) preposterous. Imagine your OS took away your hierarchical filesystem and
 required you to type
 $EDITOR homelarsdevQt5qtbasesrccorelibkernelqobject.h
 every time. How long until you'd go mad? But hey, you cannnot _not_ see
 the path of each file, even when someone pastes it on the internet.
  But this is what you're imposing on your users. It's ok as long as it was
  just Q. That's cute. But QDesignerCustomWidgetCollectionInterface or
  QDeclarativeNetworkAccessManagerFactory is *NOT* cute. It's ridiculous.

[1] And no-one, not even QtC, uses so many libraries as KMail does. If you are
looking for namespace experience, look there.

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Avoid overloading of 'error'

[Smith Martin]

err is the verb. To err is human. onErr: to forgive is divine.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Thiago Macieira thiago.macie...@intel.com
Sent: Sunday, June 14, 2015 6:55 PM
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'

On Sunday 14 June 2015 15:35:37 Lorn Potter wrote:
 On 14/06/2015 1:01 pm, Alan Alpert wrote:
  On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter lorn.pot...@gmail.com
wrote:
  On 11/06/2015 12:36 am, Samuel Gaist wrote:
  failed doesn't always mean there was an error with a direct relation.
 
  I was going to say this, but you beat me to it.
  Also, errored is just wrong, error is also past tense.
 
  I consulted a linguist. She said that if you wanted to use error as a
  verb (it's not normally one), errored would be the past tense. But
  that it's probably not the best choice of word.

 She's wrong. 'errored' is not even in the American English or the Oxford
 English dictionaries.

 http://www.merriam-webster.com/dictionary/suggestions/errored
 http://www.oxforddictionaries.com/spellcheck/english/?q=errored

They don't seem to be listing error as a verb. Wiktionary has it:
https://en.wiktionary.org/wiki/error#Verb

But the point is that there is contention on the issue, so we shouldn't use
error as a verb.
--
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] Avoid overloading of 'error'

[Smith Martin]

If you are saying you didn't know what onError meant, then I truly am 
astonished. Understanding onError, given all the other onThis and onThat we 
have in QML, really doesn't depend on the This or the That being a verb. I 
didn't mean that any of these phrases translates well into other languages.

I suppose it should have been done with when instead of on.


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Konrad Rosenbaum kon...@silmor.de
Sent: Saturday, June 13, 2015 12:53 PM
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'

On Thursday 11 June 2015 07:29:51 Smith Martin wrote:
 onError is immediately understood by all sentient beings in the universe.

So, apparently either Germans are not sentient or from outside this
universe. Might explain a lot about me...

At the very least I disagree with your use of immediately.

The phrase on error has no immediate translation in some languages - e.g.
in German it has to be translated to  nach Fehler (after error) instead
of the more literal auf Fehler (on-top-of error) or the intuitive (but
very wrong) an Fehler (at/next-to error).

On the other hand onSuccess always sounds like a toast to me (Auf den
Erfolg! - To success!) and it takes me a while to understand why a
program would believe in performing rituals for good luck.

It might be this oddity of my language, but I really hate this whole
onSomething style - it reeks of hungarian notation and seems completely
superfluous.


Either way, since I don't care much about QML/JS - do whatever you like
there. But PLEASE do not ruin it for the C++ side!


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

Re: [Development] Avoid overloading of 'error'

[Smith Martin]

onError is immediately understood by all sentient beings in the universe.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Christian Kandeler christian.kande...@theqtcompany.com
Sent: Thursday, June 11, 2015 9:21 AM
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'

On 06/10/2015 06:42 PM, Thiago Macieira wrote:
 On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
 Hi,

 I think renaming the getter to lastError is nice! I however do like error as
 signal name and it looks good in qml as onError:...

 onError screams of Basic to me...
   ON ERROR GO SUB foo
 or worse
   ON ERROR RESUME

 I don't mind the getter still being named error because it's a noun and we
 name our properties (and thus the getters) after nouns.

 The problem is the signal: the coding style is that signals are named after
 verbs in the past, indicating that something happened. error has no verb in
 the past. Even errored would be better, though that's unusual.

 I think error + verb in the past is best, so here are my suggestions, in no
 particular order:

   errorHappened
   errorCaught
   errorEncountered
   errorOccurred   (people will get the double r wrong)
   https://en.wiktionary.org/wiki/occured
   errorFound
   errorDetected
   errorDiscovered
   errorNoticed
   errorSeen
   errorObserved

 alternatively, with the verb in the active:

   caughtError
   foundError
   detectedError
   discoveredError
   noticedError
   sawError
   observedError

 If I break out the thesaurus, then we also have

   errorBefell

I would +2 this one immediately, even if it's the last thing I do before
losing my approver rights.


Christian
___
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] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

[Smith Martin]

The reason I pressed the point is that you all seem to accept uncritically the 
statement that reference parameters are confusing. Of all the things I get 
confused about in C++, reference parameters isn't one of them. I do get 
confused, but I can't recall ever being confused by one. Aren't they more 
efficient, when 0 is not a permitted value? Would swap() be as efficient with 
pointers?

I suppose my bias arises from my ancient past, when there were always limits to 
contend with.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Alejandro Exojo s...@badopi.org
Sent: Monday, May 18, 2015 2:56 PM
To: development@qt-project.org
Subject: Re: [Development] Fwd: QTextStream::readLine(0) is an ambiguous
overload in 5.5

El Monday 18 May 2015, Smith Martin escribió:
 You omitted that toInt(ok) is required to test ok for null, which is not
 required if ok is a reference.

That's extra work in the implementation in order support a nicer API to the
users, e.g. to support toInt() with the null value as default argument, in
addition to the passing a pointer makes clear that the value could be
modified.

And if you don't agree with argument, note that it's what Qt users might
expect since Qt 4 at least:

http://doc.qt.digia.com/qq/qq13-apis.html#pointersorreferences

(...) I want to share some of our findings and present the principles we've
been using when designing Qt 4 (...)

And it's common in more projects and code conventions, e.g.:

https://google-
styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
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] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Smith Martin]

When I'm reading code and I encounter a function call with parameters, if I am 
not familiar with that function, I look at its documentation. First I look at 
the signature. If it contains a non-const reference, I know the parameter can 
be modified. I read the function documentation to see if it is meant to be 
modified.


What is required inside the function if a pointer is used instead? Is the 
function required to test the pointer for nil and return in an error state or 
report an error? That doesn't happen with a reference.


martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Andreas Aardal Hanssen andr...@hanssen.name
Sent: Monday, May 18, 2015 11:44 AM
To: development
Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 
5.5

2015-05-18 11:40 GMT+02:00 André Somers 
an...@familiesomers.nlmailto:an...@familiesomers.nl:
Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35:
Qt convention is to promote pointers for out parameters to make it immediately 
clear that your input can be modified. Out references, or non-const reference 
parameters, have traditionally been discouraged because they make the code 
harder to read. It's not about what's proper C/C++.
Pointers can be just as opague. In terms of the above example: I cannot see 
from any of the parameters to those functions what their types are. If they are 
already pointers, they may already get modified. On the other hand: that 
pointer may not get modified at all.
I created https://bugreports.qt.io/browse/QTCREATORBUG-14468 for some tooling 
support to get a better feedback on what's going on.

At the end of the day, tmp is always a pointer, whereas tmp may not be. It's 
simply easier to read. Having reference out parameters is a API design mistake 
in Qt. Agree or not but deviating from this makes for an inconsistent API.

Andreas

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

Re: [Development] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

[Smith Martin]

You omitted that toInt(ok) is required to test ok for null, which is not 
required if ok is a reference.


martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Andreas Aardal Hanssen andr...@hanssen.name
Sent: Monday, May 18, 2015 12:10 PM
To: development
Subject: [Development] Fwd: QTextStream::readLine(0) is an ambiguous overload 
in 5.5


2015-05-18 11:54 GMT+02:00 Smith Martin 
martin.sm...@theqtcompany.commailto:martin.sm...@theqtcompany.com:

When I'm reading code and I encounter a function call with parameters, if I am 
not familiar with that function, I look at its documentation. First I look at 
the signature. If it contains a non-const reference, I know the parameter can 
be modified. I read the function documentation to see if it is meant to be 
modified.

What is required inside the function if a pointer is used instead? Is the 
function required to test the pointer for nil and return in an error state or 
report an error? That doesn't happen with a reference.

Hi Martin :-).

IMO Qt's first level of helpfulness is its API. The code should be 
self-explaining and self-documenting if possible. Then, if you cannot figure 
out what a function does, Qt provides first class documentation. Which is why 
QList has append and prepend instead of push_back and push_front :-).

bool ok = false;
int foo = variable.toInt(ok); // need doc
int foo = variable.toInt(ok); // dont need doc

Again though, this is procrastinating. Unless something significant has changed 
in C++ the last 10 years with regards to pointers and references I'd just 
continue sticking to what has always been the convention. Otherwise going 
through all Qt's api and changing it from pointers to references would be 
required. IMO.

--
Andreas Aardal Hanssen


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

Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Smith Martin]

How do you get bitten by an out-reference?


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Giuseppe D'Angelo dange...@gmail.com
Sent: Sunday, May 17, 2015 9:43 PM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 
5.5

On Sun, May 17, 2015 at 10:17 PM, Marc Mutz marc.m...@kdab.com wrote:

 *Any* form of out parameter is bad code policy. Much better in virtually all
 cases to return multiple values in a small struct.

No, I was simply referring to the specific case of using pointers
instead of references. I've been bitten too many times by
out-references. Then whether we should ban out-arguments is another
story entirely...

--
Giuseppe D'Angelo
___
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] QTextStream::readLine(0) is an ambiguous overload in 5.5

[Smith Martin]

I think output parameters are supposed to be placed at the end; their names 
should indicate that they are outputs, and the documentation should say they 
are changed by the function.

martin


From: Giuseppe D'Angelo dange...@gmail.com
Sent: Sunday, May 17, 2015 9:57 PM
To: Smith Martin
Cc: Marc Mutz; development@qt-project.org
Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 
5.5

On Sun, May 17, 2015 at 9:55 PM, Smith Martin
martin.sm...@theqtcompany.com wrote:
 How do you get bitten by an out-reference?

As usual, because at call site I didn't realize the argument was
actually being modified. Compare

doSomething(param1, param2, param3);
doSomething(param1, param2, param3);

which one is likely to be modifying arguments?

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

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Smith Martin]

So, no, I don't think we should discuss everthing ever written about C++ 
efficiency in the Qt docs. But we need to point it out to each other in code 
reviews and become better at not writing sloppy code.

The suggestion was not to discuss everything about C++ efficiency but to 
discuss the traps for young players using a QMap when a sorted QVector would be 
better.

IOW: We need to start thinking about our algorithms and data structures 
again[1], but this time in the new world of caches and multithreading where 
the only fast data structure is an array.[2]

But if this is a new world, then the CS course and reference books you 
suggested might not say much about it yet.

I'll bet most of our customers are not the C++ equivalents of Bruce Lee you 
imagine them to be. Some of them might be coming to C++ via trying to create 
something in QML.

martin



From: m...@kdab.com m...@kdab.com on behalf of Marc Mutz marc.m...@kdab.com
Sent: Tuesday, February 10, 2015 10:51 AM
To: Ziller Eike
Cc: Smith Martin; development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, 
etc.)

On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
  On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com wrote:
 
  On Monday 09 February 2015 09:54:12 Smith Martin wrote:
  This is the kind of thing we should add to the documentation, but can
  you elaborate? I mean, illustrate the meaning of locality of
  reference, wildly mixing insertions, lookups, and removals, and
  batch updates and separate them from lookups, time-wise.
 
  There is a book, Effective STL, and an online paper, What every
  programmer needs to know about memory. I don't think that it's the job
  of the Qt docs to explain what every programmer needs to know about
  memory, because it is not specific to Qt.
 
  The Qt documentation also doesn't give many details on Unicode. It's
  assumed that people using it know the basics.
 
  You will also not find in the Qt docs that signed integer overflow is
  undefined behaviour.
 
  The Qt docs are not a CS text book :)

 That QMap is implemented based on a RB tree is mentioned in a single
 sentence in the beginning of the description of the class, which is the
 sentence that nobody ever reads (because it tends to contain useful
 information like The QList class is a template class that provides
 lists.”).

 It is followed by a short (but longer) comparison between QMap and QHash,
 which in turn is linked to a relatively long section that compares the
 complexity of Qt’s different containers. So, fact is that the Qt docs *do*
 explain more than “QMap is a RB tree” (and I think that is good so). And
 since they talk a lot about algorithmic complexity, it would probably be
 useful to mention a few other things that concern performance differences
 as well. In ~5 sentences. I really can’t see how that could hurt.

 Actually you sounded like you’d like to educate people about this also
 “outside of CS courses” (by sending them to their manager etc), so do you
 have a different, realistic proposal?

The topic of this thread is guidelines for Qt code, not code using Qt. We
don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users of
Qt. Likewise, if they want to use QMap, then that's fine. A profiler will tell
them if they made a mistake that matters.

The situation is different for Qt code:

Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a
QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A
very naïve benchmark (I'm allowed to say that, it was my choice). was sped up
by 30%. The naïviteé in the benchmark is that this includes repeated
allocation of a handful of QString arguments from short (C) string literals
each time through the loop, which probably dominates the result.

We don't know what Qt is being used for, so we need to optimize everything.
One user surely will run multiArg() in a tight loop and that will dominate his
runtime. As every C++ library that's any good, we cannot be sloppy when it
comes to efficiency.

So, no, I don't think we should discuss everthing ever written about C++
efficiency in the Qt docs. But we need to point it out to each other in code
reviews and become better at not writing sloppy code.

IOW: We need to start thinking about our algorithms and data structures
again[1], but this time in the new world of caches and multithreading where
the only fast data structure is an array.[2]

Thanks,
Marc

[1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-
Computation/dp/0130224189

[2] http://vimeo.com/97337258

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Smith Martin]

I'm not saying that the docs should not contain some information. I'm saying 
that this is not about our users, it's about us, the developers.

I'm just adding that for some of the points you raised, if they have to be 
raised for us, the developers, it's a good bet they our users will benefit from 
them as well.

martin

From: m...@kdab.com m...@kdab.com on behalf of Marc Mutz marc.m...@kdab.com
Sent: Tuesday, February 10, 2015 11:35 AM
To: Smith Martin
Cc: Ziller Eike; development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, 
etc.)

On Tuesday 10 February 2015 11:01:50 Smith Martin wrote:
 So, no, I don't think we should discuss everthing ever written about C++
 efficiency in the Qt docs. But we need to point it out to each other in
 code  reviews and become better at not writing sloppy code.

 The suggestion was not to discuss everything about C++ efficiency but to
 discuss the traps for young players using a QMap when a sorted QVector
 would be better.

I'm not saying that the docs should not contain some information. I'm saying
that this is not about our users, it's about us, the developers.

 IOW: We need to start thinking about our algorithms and data structures
 again[1], but this time in the new world of caches and multithreading
 where  the only fast data structure is an array.[2]

 But if this is a new world, then the CS course and reference books you
 suggested might not say much about it yet.

http://www.akkadia.org/drepper/cpumemory.pdf Note the publication date.

 I'll bet most of our customers are not the C++ equivalents of Bruce Lee you
 imagine them to be. Some of them might be coming to C++ via trying to
 create something in QML.

Again, I'm not talking to or about our users, I'm talking to and about us, the
developers.

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Smith Martin]

For those guys, no amount of documentation will save them from writing 
bad code, so I don't think we should concern ourselves much with this case.

I'm happy with the documentation if an educated developer reads it, and 
is able to make the correct decision on which container class to use.

You're sort of nullifying the concept of recommending best practices at all.

We won't be asking the developers to include basic CS concepts when documenting 
a new class, if that's a worry. In this case, I asked for clarification of some 
points, so I could add a recommendation to QMap myself.

I use QMap all the time, and almost certainly in situations where a vector 
would be better. Why? Because it's dead simple and I need to get it running 
now. I suppose we get used to doing the same thing the same way and don't 
always pay attention to these details when a deadline is fast approaching. It 
helps to be reminded of best practice tips from time to time when checking a 
class I use out of habit.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Smith Martin martin.sm...@theqtcompany.com
Sent: Tuesday, February 10, 2015 12:20 PM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, 
etc.)

I'm not saying that the docs should not contain some information. I'm saying
that this is not about our users, it's about us, the developers.

I'm just adding that for some of the points you raised, if they have to be 
raised for us, the developers, it's a good bet they our users will benefit from 
them as well.

martin

From: m...@kdab.com m...@kdab.com on behalf of Marc Mutz marc.m...@kdab.com
Sent: Tuesday, February 10, 2015 11:35 AM
To: Smith Martin
Cc: Ziller Eike; development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, 
etc.)

On Tuesday 10 February 2015 11:01:50 Smith Martin wrote:
 So, no, I don't think we should discuss everthing ever written about C++
 efficiency in the Qt docs. But we need to point it out to each other in
 code  reviews and become better at not writing sloppy code.

 The suggestion was not to discuss everything about C++ efficiency but to
 discuss the traps for young players using a QMap when a sorted QVector
 would be better.

I'm not saying that the docs should not contain some information. I'm saying
that this is not about our users, it's about us, the developers.

 IOW: We need to start thinking about our algorithms and data structures
 again[1], but this time in the new world of caches and multithreading
 where  the only fast data structure is an array.[2]

 But if this is a new world, then the CS course and reference books you
 suggested might not say much about it yet.

http://www.akkadia.org/drepper/cpumemory.pdf Note the publication date.

 I'll bet most of our customers are not the C++ equivalents of Bruce Lee you
 imagine them to be. Some of them might be coming to C++ via trying to
 create something in QML.

Again, I'm not talking to or about our users, I'm talking to and about us, the
developers.

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Smith Martin]

In the vast majority of cases, a sorted vector is much faster, due to
   locality-of-reference. A RB-tree is optimized for wildly mixing insertions,
   lookups, and removals. When you can batch updates and separate them from
   lookups, time-wise, then a sorted vector is usually preferrable.

This is the kind of thing we should add to the documentation, but can you 
elaborate? I mean, illustrate the meaning of locality of reference, wildly 
mixing insertions, lookups, and removals, and batch updates and separate them 
from lookups, time-wise.

martin



From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Marc Mutz marc.m...@kdab.com
Sent: Sunday, February 8, 2015 2:28 PM
To: development@qt-project.org
Cc: Thiago Macieira
Subject: Re: [Development] Upgrading the sources to C++11 keywords  
(Q_NULLPTR, etc.)

Hi,

Sorry for being late, didn't see the thread before.

On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
 I think it's time to institute a policy that we should fix our sources to
 use the new C++11 keywords. I'd like to propose the following.

I totally agree, with the following amendments:

1. override - before adding an overriding function to a class, add
   Q_DECL_OVERRIDE to all members in a separate commit, to avoid said
   warning.

2. noexcept/nothrow - the only difference between the two is that nothrow may
   expand to throw() on compilers that implement semantics close to noexcept
   for that, and not the C++98 standard behaviour. This is currently only the
   case for MSVC, even though I believe GCC has a switch to emulate MSVC here.
   The semantic difference currently, is: when you violate noexcept, you're
   getting C++11 behaviour (std::terminate is called) or the exception leaves
   the function. If you violate nothrow, you're enterin undefined bahaviour.
   So only use nothrow if functions _cannot possibly_ throw. If you want to
   say I'm fine with errors in this function terminating the process, which
   you should be very carefully considering (it should be the exception), you
   must use noexcept instead. Obviously, if you need conditionally-noexcept,
   you must use noexcept_expr.

   Talking about warnings: there's -Wnoexcept, which warns when a
   conditionally-noexcept function turns noexecpt(false) because of a function
   that isn't marked noexcept and where the compiler can prove it doesn't
   throw. That's a bit of a mouthful, but this, too, should be added to the
   headersclean check.

   Talking about narrow contracts: A function has a narrow contract if it has
   preconditions (on it's arguments, or *this). If you have preciditions, you
   may, in debug mode, assert them as an aid to the user of your function.
   Assertions may be turned by the user (there's also a movement behind John
   Lakos, yes, _the_ John Lakos that essentially gave us the d-pointer, to
   make this standard functionality), into exception throwing (which I had
   personally good experience with during Kleopatra development). But if your
   users do this, they expect to receive those exceptions, and not terminate
   the program without a hint that an assertion was triggered).

   That's why functions with narrow contracts should not be noexcept.

   Aside: of course, you can often drop preconditions by tightening the
   interface of the function. E.g. instead of taking a naked pointer, you
   could take a non_null_ptrT, which would explode when constructed with a
   nullptr, thus making sure that every successfully constructed instance is
   actually representing a non-null pointer. Another technique is to use
   enums, because the standard says that you cannot load a value from an enum
   variable that does not correspond to one of the enumerated values. Doing
   otherwise constitutes undefined behaviour, and compilers are getting oh-so-
   good at exploiting UB that your only chance is to learn about and avoid
   them.

3. nullptr - On top of the warning, which I wasn't aware about, I find the
   code easier to read. It's a mouthful, but it's what everyone will be using
   five years from now, so we might as well start it now. I treat this as a
   whitespace error, meaning I correct it whenever I touch a line of code for
   unrelated changes.

I would add the following, unrelated to C++11, but found all over the place in
Qt, and it's next to impossible to root out: Algorithmic ineffciency. That's a
large blob, but the most important instances of it are:

a. Not marking types as movable or primitive. We might actually want to have
   a policy to mark complex types explicitly as complex, to allow easier
   fixing of missing declarations.
   The rule here should be that every new class or struct that may at some
   point be held in a container must have a q_declare_typeinfo. Rationale:
   it's impossible to add them after release, since 

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Smith Martin]

Everyone wishing to use a QMap should implement one before
using it for the first time. Then you'd see what you inflict on the world.

If that sentiment is valid, then we owe it to our users who are contemplating 
using a QMap to explain to them when and why a QMap should be used and when and 
why a QVector should be used instead.  

IMHO: A lot of this is information you find in a CS course or in a book.
Not in the Qt documentation.

I came out of a CS course, but I would find that information helpful. Plus, we 
hope to attract users to Qt who didn't come out of a CS course. 

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Bo Thorsen b...@vikingsoft.eu
Sent: Monday, February 9, 2015 12:05 PM
To: development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords  
(Q_NULLPTR, etc.)

On 02/09/2015 09:54 AM, Smith Martin wrote:

 In the vast majority of cases, a sorted vector is much faster, due to
 locality-of-reference. A RB-tree is optimized for wildly mixing 
 insertions,
 lookups, and removals. When you can batch updates and separate them from
 lookups, time-wise, then a sorted vector is usually preferrable.

 This is the kind of thing we should add to the documentation, but can you 
 elaborate? I mean, illustrate the meaning of locality of reference, wildly 
 mixing insertions, lookups, and removals, and batch updates and separate 
 them from lookups, time-wise.

IMHO: A lot of this is information you find in a CS course or in a book.
Not in the Qt documentation.

That said, there is certainly room for more info on performance impact
in the Qt documentation. The discussion a while ago about what calls
removes the effect of reserve() was one example.

Bo.

 
 From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 development-bounces+martin.smith=theqtcompany@qt-project.org on behalf 
 of Marc Mutz marc.m...@kdab.com
 Sent: Sunday, February 8, 2015 2:28 PM
 To: development@qt-project.org
 Cc: Thiago Macieira
 Subject: Re: [Development] Upgrading the sources to C++11 keywords  
 (Q_NULLPTR, etc.)

 Hi,

 Sorry for being late, didn't see the thread before.

 On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote:
 I think it's time to institute a policy that we should fix our sources to
 use the new C++11 keywords. I'd like to propose the following.

 I totally agree, with the following amendments:

 1. override - before adding an overriding function to a class, add
 Q_DECL_OVERRIDE to all members in a separate commit, to avoid said
 warning.

 2. noexcept/nothrow - the only difference between the two is that nothrow may
 expand to throw() on compilers that implement semantics close to noexcept
 for that, and not the C++98 standard behaviour. This is currently only the
 case for MSVC, even though I believe GCC has a switch to emulate MSVC 
 here.
 The semantic difference currently, is: when you violate noexcept, you're
 getting C++11 behaviour (std::terminate is called) or the exception leaves
 the function. If you violate nothrow, you're enterin undefined bahaviour.
 So only use nothrow if functions _cannot possibly_ throw. If you want to
 say I'm fine with errors in this function terminating the process, which
 you should be very carefully considering (it should be the exception), you
 must use noexcept instead. Obviously, if you need conditionally-noexcept,
 you must use noexcept_expr.

 Talking about warnings: there's -Wnoexcept, which warns when a
 conditionally-noexcept function turns noexecpt(false) because of a 
 function
 that isn't marked noexcept and where the compiler can prove it doesn't
 throw. That's a bit of a mouthful, but this, too, should be added to the
 headersclean check.

 Talking about narrow contracts: A function has a narrow contract if it has
 preconditions (on it's arguments, or *this). If you have preciditions, you
 may, in debug mode, assert them as an aid to the user of your function.
 Assertions may be turned by the user (there's also a movement behind John
 Lakos, yes, _the_ John Lakos that essentially gave us the d-pointer, to
 make this standard functionality), into exception throwing (which I had
 personally good experience with during Kleopatra development). But if your
 users do this, they expect to receive those exceptions, and not terminate
 the program without a hint that an assertion was triggered).

 That's why functions with narrow contracts should not be noexcept.

 Aside: of course, you can often drop preconditions by tightening the
 interface of the function. E.g. instead of taking a naked pointer, you
 could take a non_null_ptrT, which would explode when constructed

Re: [Development] Nominating Timur Pocheptsov as approver

[Smith Martin]

And +1 from me.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Rutledge Shawn shawn.rutle...@theqtcompany.com
Sent: Thursday, January 22, 2015 11:49 AM
To: development@qt-project.org
Subject: Re: [Development] Nominating Timur Pocheptsov as approver

+1 from me

On Jan 22, 2015, at 7:52, Blasche Alexander 
alexander.blas...@theqtcompany.com wrote:

 Hi,

 I'd like to nominate Timur Pocheptsov for approver status. He wrote the OSX 
 and iOS implementations for QtBluetooth and lately has been increasing his 
 footprint in other modules for the same platforms.

 https://codereview.qt-project.org/#/q/owner:tpochep,n,z
 https://codereview.qt-project.org/#/q/reviewer:tpochep,n,z

 A big thank you from me to Timur.
 --
 Alex
 ___
 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way of pushing to gerrit

[Smith Martin]

 years of preaching don't rebase unnecessarily and don't create
 spurious dependencies being mostly ineffective. 

I speak for all the people who play Myst by just walking around the island 
enjoying the views and listening to the waves.

We don't know when it is necessary to rebase, except when we get the message 
Please rebase the change locally..., and even then we don't really understand 
what is wrong. And we don't know when we are creating spurious dependencies 
because we don't know we are creating dependencies at all.  We just do:

git commit -a -F ./commit.txt
git pull --rebase
git push origin HEAD:refs/for/dev

We do the rebase step because we were told that was the right thing. In Myst, 
how do you get out to that island to pull the lever?

 martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Joerg Bornemann joerg.bornem...@theqtcompany.com
Sent: Friday, October 24, 2014 11:45 AM
To: development@qt-project.org
Subject: Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way 
of pushing to gerrit

On 24-Oct-14 11:37, Oswald Buddenhagen wrote:

 What is rationale for the technical enforcement?

 years of preaching don't rebase unnecessarily and don't create
 spurious dependencies being mostly ineffective. i pushed an update to
 your change, take care not to overwrite it accidentally being futile on
 a regular basis. people demanding ridiculously short review cycles,
 because waiting for a review holds them up for 'process' reasons. etc.
 iow, the usual results of inattentivenes, indifference (unless one is
 the reviewer affected by it, of course), impatience, and sheer laziness.
 and sometimes even genuine mistakes.

I for one already did this manually where it made sense.
Some of us don't.

Anyways, you missed the chance to convince people from the awesomeness
of your script before pissing everybody off with your megalomania.


Joerg
___
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] Qdoc || !Qdoc

[Smith Martin]

Thanks, Kevin.

Do you know how doxygen finds those links? Does it use the qdoc index files, or 
does it construct an index from all the Qt html files?

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Kevin Kofler kevin.kof...@chello.at
Sent: Wednesday, October 22, 2014 3:44 AM
To: development@qt-project.org
Subject: Re: [Development] Qdoc || !Qdoc

Smith Martin wrote:
 If you want your documentation to link to the Qt documentation, it might
 be easier to use qdoc. I'm not sure that's correct, because I haven't
 actually used doxygen for that purpose, but I know you can link to Qt
 documentation using qdoc.

Doxygen can definitely link to Qt documentation, see e.g.:
http://api.kde.org/frameworks-api/frameworks5-apidocs/kcoreaddons/html/classKProcess.html
(which is generated using Doxygen, as all KDE API documentation).

You have to explicitly set it up for that though.

Kevin Kofler

___
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] Qdoc || !Qdoc

[Smith Martin]

I suspect this means we no longer need the .index files in qdoc. We should have 
used the tag files beginning with 5.0. 

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Miettinen Riitta-Leena riitta-leena.mietti...@theqtcompany.com
Sent: Wednesday, October 22, 2014 10:46 AM
To: development@qt-project.org
Subject: Re: [Development] Qdoc || !Qdoc

Hello,

Take a look at a recent blog post by Lorenz Haas on Linking Qt classes in 
documentation generated with Doxygen: 
http://blog.qt.digia.com/blog/2014/08/13/qt-weekly-17-linking-qt-classes-in-documentation-generated-with-doxygen/

Best regards,

Leena Miettinen Documentation Engineer | The Qt Company

Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Email: email@theqtcompany.com | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: 
http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: 
www.facebook.com/qt

 Date: Wed, 22 Oct 2014 09:39:58 +0200
 From: Oleksii Serdiuk conta...@oleksii.name
 Subject: Re: [Development] Qdoc || !Qdoc
 To: development@qt-project.org
 Message-ID: 54475f4e.1090...@oleksii.name
 Content-Type: text/plain; charset=windows-1252

 Hello Martin,

 Yes, it uses index files. In Qt 4 times it was one file (qt-4.8.tags),
 but now they're split per-module (qtcore.tags, qtgui.tags, ...).

 In Doxyfile you have to set TAGFILES to path to .tags file and URL to Qt
 documentation. If you need an example, you can take a look at
 https://github.com/leppa/tspsg/blob/master/Doxyfile, line 2029.

 And if I'm not mistaken, doxygen can also generate .tags file from HTML.

 On 22/10/14 08:39, Smith Martin wrote:
 Thanks, Kevin.

 Do you know how doxygen finds those links? Does it use the qdoc index files, 
 or does it construct an index from all the Qt html files?

 martin
 
 From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 development-bounces+martin.smith=theqtcompany@qt-project.org on behalf 
 of Kevin Kofler kevin.kof...@chello.at
 Sent: Wednesday, October 22, 2014 3:44 AM
 To: development@qt-project.org
 Subject: Re: [Development] Qdoc || !Qdoc

 Smith Martin wrote:
 If you want your documentation to link to the Qt documentation, it might
 be easier to use qdoc. I'm not sure that's correct, because I haven't
 actually used doxygen for that purpose, but I know you can link to Qt
 documentation using qdoc.

 Doxygen can definitely link to Qt documentation, see e.g.:
 http://api.kde.org/frameworks-api/frameworks5-apidocs/kcoreaddons/html/classKProcess.html
 (which is generated using Doxygen, as all KDE API documentation).

 You have to explicitly set it up for that though.

Kevin Kofler

 --
 With best regards,
 Oleksii Serdiuk

 -- next part --
 A non-text attachment was scrubbed...
 Name: smime.p7s
 Type: application/pkcs7-signature
 Size: 4813 bytes
 Desc: S/MIME Cryptographic Signature
 Url : 
 http://lists.qt-project.org/pipermail/development/attachments/20141022/d0709696/attachment-0001.bin


___
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] Qdoc || !Qdoc

[Smith Martin]

?You can use either doxygen or qdoc, but the two have different command sets, 
so they aren's interchangeable.


If you want your documentation to link to the Qt documentation, it might be 
easier to use qdoc. I'm not sure that's correct, because I haven't actually 
used doxygen for that purpose, but I know you can link to Qt documentation 
using qdoc.


martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Federico Buti bacaro...@gmail.com
Sent: Tuesday, October 21, 2014 11:36 AM
To: Shivashankar Venugopal
Cc: development@qt-project.org
Subject: Re: [Development] Qdoc || !Qdoc

?Thanks for the fast response! I'm going to have a look to the documentation.
Just to be totally sure: your answer implies that, as an external user of Qt 
(not a developer), it is now advisable to switch from Doxygen to qdoc, right? 
Or using qdoc is only suggested for Qt APIs?
Thanks again,
F.

?---?

On 21 October 2014 11:23, Shivashankar Venugopal 
venugopal.shivashan...@theqtcompany.commailto:venugopal.shivashan...@theqtcompany.com
 wrote:
Hi,

qdoc3 is renamed as qdoc since Qt 5.0. You should find all the details you need 
about qdoc on http://doc-snapshot.qt-project.org/qdoc/qdoc-index.html. Find us 
on the #qt-documentation channel on freenode if you have any questions.

Venu
___
Development mailing list
Development@qt-project.orgmailto: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] Compiler warnings

[Smith Martin]

But if lack of a parameter name means unused (by choice) parameter, then 
compilers shouldn't warn that it is an unused parameter.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Kevin Kofler kevin.kof...@chello.at
Sent: Thursday, October 16, 2014 7:46 PM
To: development@qt-project.org
Subject: Re: [Development] Compiler warnings

Smith Martin wrote:
 But maintaining binary compatibility is now a necessary facet of software
 engineering, so maybe it is time for the C++ standard to support it. A
 keyword could be added to the parameter declaration, compatibility or
 placeholder for example, could precede a parameter declaration that is
 kept for binary compatibility. The compiler would not warn that the
 parameter was not used.

The lack of a name for the parameter is already how the C++ standard
specifies unused parameters, and g++ normally does NOT warn in that case.

In addition, GCC/g++ has supported __attribute__((unused)) for ages. For Qt
code, there's also the Q_UNUSED macro, which is used in the function itself,
and which should work with most (if not all) compilers out there. But all
those should not be needed in cases where you can simply omit the parameter
name.

Kevin Kofler

___
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] Compiler warnings

[Smith Martin]

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of 
Poenitz Andre andre.poen...@theqtcompany.com
Sent: Wednesday, October 15, 2014 9:48 AM
To: Kurt Pattyn; Bo Thorsen
Cc: development@qt-project.org
Subject: Re: [Development] Compiler warnings

Kurt Pattyn pattyn.k...@gmail.com wrote:
  On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote:
 
  Den 14-10-2014 08:59, Kurt Pattyn skrev:
  how do these applications comply with MISRA?
 
  MISRA is impossible to comply with for a framework. For example,
   consider the required rule 0-1-11: There shall be no unused parameters
   (named or unnamed) in non-virtual functions.
 
  With this, void f(int /*no_longer_used*/) is illegal. For any
  non-trivial framework that keeps binary compatibility, this will over time 
  be hit.

 On second thought, I think this is a very bad example. Even while you keep
  binary compatibility, you break semantics here.
 This is typically a case where one should break binary compatibility.

Are you seriously asking for a new major Qt release just because a
new implementation of some function does not require some parameter
anymore?

But maintaining binary compatibility is now a necessary facet of software 
engineering, so maybe it is time for the C++ standard to support it. A keyword 
could be added to the parameter declaration, compatibility or placeholder 
for example, could precede a parameter declaration that is kept for binary 
compatibility. The compiler would not warn that the parameter was not used.

martin

___
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] [docs/c++] How do we deal with the special member functions (copy/move ctor/assignment operator, dtor, default ctor)

[Smith Martin]

A JIRA task has been created: 
https://bugreports.qt-project.org/browse/QTBUG-40589

Add more examples of what you would like to see.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Knoll 
Lars [lars.kn...@digia.com]
Sent: Monday, August 04, 2014 2:46 PM
To: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] [docs/c++] How do we deal with the special member 
functions (copy/move ctor/assignment operator, dtor, default ctor)

On 04/08/14 14:27, Thiago Macieira thiago.macie...@intel.com wrote:

On Monday 04 August 2014 09:31:12 Marc Mutz wrote:
 On Monday 04 August 2014 08:02:51 Knoll Lars wrote:
  On 02/08/14 18:21, Thiago Macieira thiago.macie...@intel.com
wrote:
  Why do we have to document them in the first place? I hate having to
  write
  documentation for a destructor that simply says frees resources
  associated
  with this object.

 Ok, fair enough, but how, then, is a user-defined special member
function
 (where user = Qt developers) different, assuming, of course, that the
user-
 defined copy ctor actually copies...? It's an implementation detail
whether
 the implicit version works or whether a user implementation is
necessary..
 By documenting one and not the other, we either leak that information,
or
 make new C++ users think that some classes - that are - aren't copyable.

As I said, I'd rather not document any of them if they don't do anything
special and don't have user-visible impacts. The fact that we had to
document
a few notwithstanding: we should modify qdoc so there's a way to document
a
type as copyable and also suppress those special constructors in the docs.

 Worse: unless you look at the header file, there's no way to predict
whether
 the implicitly declared, say, copy constructor is deleted or defaulted.
And
 it's not as if Q_DISABLE_COPY generates any documentation.

The solution is to make Q_DISABLE_COPY generate documentation and mark
the
type as non-copyable.

 So maybe the real questions is, as Thiago said, how to document whether
a
 class is a value class or polymorphic (though, of course, there are more
 than these two: move-only classes, RAII classes (with some overlap
between
 the two, etc)).

 \valueclass
 \polymorphic
 \raii
 \move-only

 Or just

 \implicitdefaultctor
 \impicitcopyctor
 \implicitmovector
 \implicitdtor
 \implicitcopyassignment \ \implicitassignment
 \implicitmoveassignment /

I'd rather have \valueclass and Q_DISABLE_COPY. The in-between cases will
require per-method documentation.

I’d agree with this. Qdoc could add some standard wording for a class that
can be copied (or not), and then we can get rid of the explicit
documentation for copy constructors and assignment operators. And let’s
document special cases where required.

Cheers,
Lars

___
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] [docs/c++] How do we deal with the special member functions (copy/move ctor/assignment operator, dtor, default ctor)

[Smith Martin]

qdoc decides which members must be documented by parsing the .h file looking 
for the members that are not private. Any such member that does not later have 
a qdoc comment is a documentation missing error. It has simply always been 
that way, but we can change it if that makes sense. It does recognize the 
constructors and destructor. The way to tell qdoc to ignore a member is to give 
it a qdoc comment that contains nothing but \internal

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago 
Macieira [thiago.macie...@intel.com]
Sent: Saturday, August 02, 2014 6:21 PM
To: development@qt-project.org
Subject: Re: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)

On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
 That leaves the question how to deal with the documentation for these
 implicit  members.

Why do we have to document them in the first place? I hate having to write
documentation for a destructor that simply says frees resources associated
with this object. That much is obvious: any self-respecting destructor will
do that and the same applies to copy and move constructors.

What we really want is to document which objects are copyable and which ones
aren't. And that is very simple: any object with Q_DISABLE_COPY is not
copyable, (almost) everything else is.

--
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] Nominating Sze Howe Koh as approver

[Smith Martin]

+1

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago 
Macieira [thiago.macie...@intel.com]
Sent: Sunday, March 23, 2014 12:50 AM
To: development@qt-project.org
Subject: [Development] Nominating Sze Howe Koh as approver

Hello

I'd like to nominate Sze Howe Koh as approver. You must have seen the number
of contributions already done in the mailing list discussions, but you may not
have seen the contributions done to Qt documentation.

Here's the link to the submissions made:
https://codereview.qt-project.org/#q,owner:szehowe@gmail.com,n,z

And reviews made:
https://codereview.qt-project.org/#q,reviewer:szehowe@gmail.com,n,z

And here are Sze's dashboard:
https://codereview.qt-project.org/#dashboard,1002192

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

[Development] This sequence for rebuilding a new qtbase on OSX doesn't work...

[Smith Martin]

cd qt5
git checkout release
git submodule update
git submodule foreach 'git clean -dxf' // this doesn't work properly
git submodule foreach 'git reset --hard'
git submodule foreach 'git checkout release ||:'
git submodule foreach 'git pull --rebase ||:'
./configure -developer-build -confirm-license -opensource -no-xcb -nomake 
examples -nomake tests
make module-qtbase-qmake_all
make module-qtbase

I get compilation errors. i.e. it can't find several .h files in angle brackets 
e.g. QList.h

To fix it, I have to do this:
cd qtbase
git clean -dxf
make

Is there something wrong with git submodule foreach 'git clean -dxf'  ?

martin

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

Re: [Development] Coding style proposal

[Smith Martin]

When I want to find a C++ function, I search for ::functionName

I feel so old.

Wait... I'll be 64 this month. I remember when I first heard the Beatles sing 
When I'm 64. I thought I would never be 64 years old. But now here I am, 
still using old reliable ctrl-s to find functions.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of André 
Somers [an...@familiesomers.nl]
Sent: Friday, January 03, 2014 12:36 PM
To: development@qt-project.org
Subject: Re: [Development] Coding style proposal

Poenitz Andre schreef op 3-1-2014 12:33:
 André Somers wrote:
 Poenitz Andre schreef op 2-1-2014 23:49:
 Jiergir Ogoerg wrote:
 Ironically, not even the IDE (QtCreator) sorts them out, in my example
 parse...() is the 1st in the list, and locale() is the last one (16th).
 There's a Sort alphabetically check box in the context menu of
 whatever-that-combobox-that-I-never-use-for-navigation-is-called.
 Well, that's a find! I wonder why it is not enabled by default?
 Probably because the current code follows the rule of Don't switch on
 a fancy option by default unless it's clearly better than the alternative,
 and I even tend to agree that the rule applies here, and the current default
 is good. But since I don't use the combobox at all, that's not a strong 
 opinion.

 If people who actually use the combobox agree that alphabetical order
 should take precedence over the order in which the functions are defined,
 the default can be changed. A patch is now on Gerrit (#74614) and awaits
 comments.
I hardly used it _because_ it was still such a hassle to find anything
in it in a larger file. That might certainly change now...

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] Coding style proposal

[Smith Martin]

Of course, in those days (that was 1966), ctrl-s hadn't even been thought of 
yet. For that matter, the keyboard didn't even exist. All we had was a keypunch 
machine.

If you really think finding a function in a C++ file is an onerous task, 
imagine what it was like punching your program into a deck of cards so you 
could get one or maybe two compilations a day. 

Maybe it's time to slow down a bit. 

martin 

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Smith 
Martin [martin.sm...@digia.com]
Sent: Friday, January 03, 2014 12:43 PM
To: André Somers; development@qt-project.org
Subject: Re: [Development] Coding style proposal

When I want to find a C++ function, I search for ::functionName

I feel so old.

Wait... I'll be 64 this month. I remember when I first heard the Beatles sing 
When I'm 64. I thought I would never be 64 years old. But now here I am, 
still using old reliable ctrl-s to find functions.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of André 
Somers [an...@familiesomers.nl]
Sent: Friday, January 03, 2014 12:36 PM
To: development@qt-project.org
Subject: Re: [Development] Coding style proposal

Poenitz Andre schreef op 3-1-2014 12:33:
 André Somers wrote:
 Poenitz Andre schreef op 2-1-2014 23:49:
 Jiergir Ogoerg wrote:
 Ironically, not even the IDE (QtCreator) sorts them out, in my example
 parse...() is the 1st in the list, and locale() is the last one (16th).
 There's a Sort alphabetically check box in the context menu of
 whatever-that-combobox-that-I-never-use-for-navigation-is-called.
 Well, that's a find! I wonder why it is not enabled by default?
 Probably because the current code follows the rule of Don't switch on
 a fancy option by default unless it's clearly better than the alternative,
 and I even tend to agree that the rule applies here, and the current default
 is good. But since I don't use the combobox at all, that's not a strong 
 opinion.

 If people who actually use the combobox agree that alphabetical order
 should take precedence over the order in which the functions are defined,
 the default can be changed. A patch is now on Gerrit (#74614) and awaits
 comments.
I hardly used it _because_ it was still such a hassle to find anything
in it in a larger file. That might certainly change now...

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documentation maintainer

[Smith Martin]

No, I think the maintainer was Casper Van Donderan.

martin
 

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Laszlo 
Papp [lp...@kde.org]
Sent: Wednesday, December 18, 2013 7:15 PM
To: Knoll Lars
Cc: Pasion Jerome; development@qt-project.org
Subject: Re: [Development] Documentation maintainer

On Tue, Dec 17, 2013 at 3:43 PM, Knoll Lars lars.kn...@digia.com wrote:
 Hi,

 I’d also like to nominate Topi Reiniö as the overall maintainer of our
 documentation. Topi has been doing an excellent job in handling and
 improving our documentation over the last year, and is IMO the best
 candidate we have for the job.

Hmm, was Jerome not holding this role? I have not seem him stepping
down on this mailing list. What happened to him?
___
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] QPA maintainer

[Smith Martin]

+1

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Knoll 
Lars [lars.kn...@digia.com]
Sent: Tuesday, December 17, 2013 12:42 PM
To: development@qt-project.org
Subject: [Development] QPA maintainer

Hi,

I’d like to nominate Paul Tvete as the formal maintainer of the QPA
architecture. He’s the original architect behind it anyway, and I don’t
think there are many people out there who know it better :)

Cheers,
Lars

___
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] Multimedia maintainer

[Smith Martin]

I'm not a maintainer either; didn't know you had to be one, but +1 anyway.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of BogDan 
[bog_dan...@yahoo.com]
Sent: Tuesday, December 17, 2013 2:47 PM
To: Knoll Lars; development@qt-project.org
Subject: Re: [Development] Multimedia maintainer

+1

Again, even if I'm not a maintainer and my vote doesn't count, but I want to 
show my gratitude for Yoann Lopes because he did a great job with Android 
multimedia!

Cheers,
BogDan.



- Original Message -
 From: Knoll Lars lars.kn...@digia.com
 To: development@qt-project.org development@qt-project.org
 Cc:
 Sent: Tuesday, December 17, 2013 11:24 AM
 Subject: [Development] Multimedia maintainer

 Hi,

 the first maintainer I’d like to nominate is Yoann Lopes for multimedia.
 Yoann has been taking care of multimedia for the last year, and done lots
 of work on the different backends.

 https://codereview.qt-project.org/#q,owner:yoann.lopes%2540digia.com,p,0028
 cb2200011062

 Cheers,
 Lars

 ___
 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documentation maintainer

[Smith Martin]

+1

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Knoll 
Lars [lars.kn...@digia.com]
Sent: Tuesday, December 17, 2013 4:43 PM
To: development@qt-project.org
Subject: [Development] Documentation maintainer

Hi,

I’d also like to nominate Topi Reiniö as the overall maintainer of our
documentation. Topi has been doing an excellent job in handling and
improving our documentation over the last year, and is IMO the best
candidate we have for the job.

Cheers,
Lars

___
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] Changed qdebug stream operator output (qtbase/dev)

[Smith Martin]

I will miss it. Why did we take it out? Now I have to puteverywhere.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Koehne 
Kai [kai.koe...@digia.com]
Sent: Friday, December 06, 2013 4:29 PM
To: development@qt-project.org
Subject: [Development] Changed qdebug stream operator output (qtbase/dev)

Hi,

Just a small heads-up: I just managed to merge change 
https://codereview.qt-project.org/#change,69731 in qtbase , dev branch. That 
change gets rid of the trailing space that was added for every qDebug()  ; 
statement. I guess nobody will really miss it ... but it might be that there 
are still auto tests checking for it!

So, if you've mysterious autotest failures in somemodule/dev where expected 
output isn't found any more, this might be the reason. Actually QTest now takes 
this into account for a simple ignoreExpectedMessage(), but that ain't help you 
if you're e.g. comparing QProcess output ...

Follow up patches for some modules are here:

QtDeclarative: https://codereview.qt-project.org/#change,69735
Qtsensors: https://codereview.qt-project.org/69734
Qtmultimedia: https://codereview.qt-project.org/#change,69732
Qtquick1: https://codereview.qt-project.org/#change,69736


Kind regards

Kai

--
   Kai Köhne, Senior Software Engineer - Digia, Qt
   Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


___
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] [Request] Compiler warnings in Qt

[Smith Martin]

I get warnings with clang in OSX. It even treats an unused variable as an error.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago 
Macieira [thiago.macie...@intel.com]
Sent: Friday, December 06, 2013 6:16 PM
To: development@qt-project.org
Subject: Re: [Development] [Request] Compiler warnings in Qt

On sexta-feira, 6 de dezembro de 2013 11:16:20, Kurt Pattyn wrote:
 When compiling applications with compiler flags on, a lot of warnings are
 generated for the Qt header files. I

Which compiler? Which warnings?

We're not supposed to have any warnings with GCC or Clang.
--
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] [Request] Compiler warnings in Qt

[Smith Martin]

Well, yes, I fix the ones that are errors, but I have seen many warnings that 
are just warnings. 

I saw an uninitialized variable in one of the Qt hash collections, but I 
haven't seen that one lately, so someone might have fixed it.

I can't recall the others at the moment. I have been ignoring them if I get a 
working QtBase, because I have assumed it is just my rarely up-to-date OSX 
environment. 

Should I report these warnings in JIRA?

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago 
Macieira [thiago.macie...@intel.com]
Sent: Friday, December 06, 2013 6:25 PM
To: development@qt-project.org
Subject: Re: [Development] [Request] Compiler warnings in Qt

On sexta-feira, 6 de dezembro de 2013 17:18:02, Smith Martin wrote:
 I get warnings with clang in OSX. It even treats an unused variable as an
 error.

Which makes you fix them, so we don't get warnings in the repository :-)
--
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] Can the hidden QML properties please be documented?

[Smith Martin]

For a QML type in a .qml file, qdoc reports an error if it sees a QML property 
it thinks should be in the public API for that QML type and there is no 
\qmlproperty comment immediately preceding that property in the .qml file.

But for a QML type that is represented by a C++ class, qdoc doesn't know which 
C++ properties are meant to be be documented as QML properties, so it can't 
report an error if a C++ property is not documented as a QML property.

Maybe we should change this policy and tell qdoc to require a \qmlproperty for 
every C++ property that has a \property ?

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Alan 
Alpert [4163654...@gmail.com]
Sent: Monday, December 02, 2013 7:32 AM
To: Mark Gaiser
Cc: development@qt-project.org
Subject: Re: [Development] Can the hidden QML properties please be
documented?

On Sun, Dec 1, 2013 at 4:25 AM, Mark Gaiser mark...@gmail.com wrote:
 On Sun, Dec 1, 2013 at 11:09 AM, Nurmi J-P jpnu...@digia.com wrote:


 On 01 Dec 2013, at 00:42, Mark Gaiser mark...@gmail.com wrote:

 Hi,

 Recently i was searching for a way to influence the dragDistance in
 QML. The documentation (i even looked at dev snapshot docs) didn't
 provide any clue, but the code did. Turns out there is a hidden
 property:

 drag.threshold (it is underlined in red in QtCreator, but works just fine!).

 Perhaps you're reading Qt 5.1.x docs? MouseArea::drag::threshold is a new 
 property that was added in September. The documentation is there in the 
 latest snapshot: 
 http://doc-snapshot.qt-project.org/qt5-release/qml-qtquick-mousearea.html


 For font rendering there is the hidden property:

 renderType

 Which works just fine, but is nowhere to be found in the Qt documentation.


 QQuickText::renderType was indeed missing from the docs. It has been fixed 
 in Qt 5.2.0:
 - https://bugreports.qt-project.org/browse/QTBUG-35018
 - https://codereview.qt-project.org/#change,72391

 --
 J-P Nurmi

 That's awesome!
 It still makes me wonder, how many more are hidden? I hope none :)

I hope so too, as it's usually a doc bug. Feel free to file further
issues like this on bugreports.qt-project.org .

--
Alan Alpert
___
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] Nominating Topi Reiniö (topi.rei...@digia.com) as approver

[Smith Martin]

Hi again,

It has been more than 15 days. We have +1's and no objections. Please update 
Topi to have Approver rights.

martin


From: Smith Martin
Sent: Tuesday, October 22, 2013 11:53 AM
To: development@qt-project.org
Subject: Nominating Topi Reiniö (topi.rei...@digia.com) as approver

I nominate Topi as an approver. Topi has been the leader of the Qt 
documentation team in Oslo for a long time.

A search for topi.rei...@digia.com at codereview.qt-project.org shows that Topi 
has been very active both submitting patches and reviewing patches for the Qt 
documentation and for the qdoc tool.

Seconds?

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

Re: [Development] Flat directory structure for Qt 5.2 documentation

[Smith Martin]

Two reasons. First, so people can enter documentation page paths without 
knowing the module subdirectory they are in. Second, so the pages will appear 
first in google searches.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of 
Nicolás Alvarez [nicolas.alva...@gmail.com]
Sent: Sunday, September 01, 2013 1:25 AM
To: development@qt-project.org
Subject: Re: [Development] Flat directory structure for Qt 5.2 documentation

2013/8/30 Pasion Jerome jerome.pas...@digia.com:
 For Qt 5.2, we plan to deliver the online documentation (qt-project.org/doc)
 using a flat documentation structure. Currently, the online documentation
 is using the modularized structure.

What's the reason for this, out of curiosity?

--
Nicolás
___
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] Flat directory structure for Qt 5.2 documentation

[Smith Martin]

The flat directory structure doesn't fix the QObject/QWidget subclass problem. 
At the moment, this is in the Too Hard category.

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of Yves 
Bailly [yves.bai...@laposte.net]
Sent: Monday, September 02, 2013 12:46 PM
To: development@qt-project.org
Subject: Re: [Development] Flat directory structure for Qt 5.2 documentation

On 02/09/2013 09:52, Smith Martin wrote:
 Two reasons. First, so people can enter documentation page paths without 
 knowing
  the module subdirectory they are in. Second, so the pages will appear first 
  in google searches.

One more reason: take the Qt5's QObject page, QWidget doesn't show in its 
subclasses.
This is true for others as well. Overall I find the documentation harder to 
navigate
since Qt4, compared to Qt3 which was a real pleasure.

--
(o | Yves Bailly  | -o)
//\ | Linux Dijon  : http://www.coagul.org | //\
\_/ |  | \_/`
___
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] 答复: 答复: [Qt-interest] QMultiHash

[Smith Martin]

values(key) returns a list of all the values with the key.

remove(key) removes all the values for key.

Then reinsert new values for key.

But why do you want to put the same key,value pair multiple times?

martin

From: development-bounces+martin.smith=digia@qt-project.org 
[development-bounces+martin.smith=digia@qt-project.org] on behalf of 
pengliang(彭亮) [pengli...@founder.com]
Sent: Thursday, March 07, 2013 12:51 PM
To: Danny Koppel; pengliang(??); development@qt-project.org
Subject: [Development] 答复: 答复: [Qt-interest] QMultiHash


hi

QMultiHashQString,long;
it allow you to insert some same keys,
i have to find some string whether exist in the hash,
if exist, then set values of hash to 0.


my program is used to remove duplicate rows in two files.
so, i read file1 to QMultiHashQString,longhash, qstring are content of rows, 
long are index of rows,
when i read one row in file2, i have to check whether hash has this row, if 
yes, i set the values of hash to 0(ignore these rows), else write this row to a 
new file.

then, create QMultiMaplong,QStringmap, insert hash to map, and loop map write 
QString to another new file.


-
who has a good advice?


thanks
ken




-Original Message-
From: Danny Koppel [mailto:d.kop...@skf-rif.nl]
Sent: 2013-3-7 (星期四) 18:11
To: 'pengliang(??)'; development@qt-project.org
Subject: RE: [Development] 答复:  [Qt-interest] QMultiHash

Hi,

If you always use replace, there won’t be double keys.
This is depending on your implementation.

Other option:
Use the find() method on the class.
Then  use an iterator on the results to assign the new value.

But if I read your mail, you suggest that you always replace ALL values with 
the same key.
(Then I would like to know why you have double keys at all?!)
So then I would just use replace. Then the key will occur only once.

I’m working with assumptions, so that’s why I ‘offer’ two solutions.

Kind regards,
Danny

Van: development-bounces+d.koppel=skf-rif...@qt-project.org 
[mailto:development-bounces+d.koppel=skf-rif...@qt-project.org] Namens 
pengliang(??)
Verzonden: donderdag 7 maart 2013 10:59
Aan: Danny Koppel; development@qt-project.org
Onderwerp: [Development] 答复: [Qt-interest] QMultiHash

Hi
1.
QmultiHash replace() is only replace first item, I want to replace all values 
when key is matched.
Qt docs : if there are multiple items with the key, the most recently inserted 
item's value is replaced with value.
Who have a better method?

2. so I need to use Qmaplong,Qstring,
I found qt source code below, so I think Qhashlong,Qstring is ordered by 
long, am I right?
inline uint qHash(long key) { return qHash(ulong(key)); }
template class T inline uint qHash(const T *key)
{
return qHash(reinterpret_castquintptr(key));
}

Thanks
Ken



发件人: Danny Koppel [mailto:d.kop...@skf-rif.nl]
发送时间: 2013年3月7日 17:39
收件人: 'pengliang(??)'; 
development@qt-project.orgmailto:development@qt-project.org
主题: RE: [Development] [Qt-interest] QMultiHash

Hello,

I don’t know if I understand you correctly but the QMultiHash class has the 
function replace which does what you describe.
It replaces the value of an existing key or creates a new one if the key 
doesn’t exist yet.
About point 2: the documentation describes it as follows: “When iterating over 
a QMapqthelp://org.qt-project.qtcore.501/qtcore/qmap.html, the items are 
always sorted by key. With QHash, the items are arbitrarily ordered.”.

Kind regards,
Danny

Van: 
development-bounces+d.koppel=skf-rif...@qt-project.orgmailto:development-bounces+d.koppel=skf-rif...@qt-project.org
 [mailto:development-bounces+d.koppel=skf-rif...@qt-project.org] Namens 
pengliang(??)
Verzonden: donderdag 7 maart 2013 10:25
Aan: development@qt-project.orgmailto:development@qt-project.org
Onderwerp: [Development] [Qt-interest] QMultiHash

Hi All

QMultiHashQstring,inthh;
I need to find some key and change their values.
I found If I use QmutableHashIteratorQstring,intit , its
bool

findNextqmutablehashiterator.html#findNext ( const T  value )

Its parameter is a value, not a key.
So I need to :
While(it.hasNext())
{
It.next();
If(it.key() == ikey)
{
It.setValue(ivalue);
}
}

I must to check every item? Who have a better method?

2. Qhash:
Some books said Qhash is unorderred?
But I test it.
QhashQstring,inthh;
I insert some string, and loop the hash by QhashIterator, I found the string is 
orderred.
And I test it Qhashint,Qstring, and print key, and found they still orderred.
Why books said it is unorderred?


Thanks

ken


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