Re: [Development] Future of Qt Quick 1 in Qt 5

2015-05-18 Thread Thiago Macieira
On Tuesday 19 May 2015 00:20:43 Stephen Kelly wrote: > Kevin Kofler wrote: > > Koehne Kai wrote: > >> One thing to worry about though is Linux distributions: We certainly > >> don't want to let them stick to an old Qt version because there are > >> applications still depending on qtquick1. However,

Re: [Development] Future of Qt Quick 1 in Qt 5

2015-05-18 Thread Stephen Kelly
Kevin Kofler wrote: > Koehne Kai wrote: >> One thing to worry about though is Linux distributions: We certainly >> don't want to let them stick to an old Qt version because there are >> applications still depending on qtquick1. However, a quick search with >> e.g. osc for openSUSE shows that this

Re: [Development] Future of Qt Quick 1 in Qt 5

2015-05-18 Thread Kevin Kofler
Koehne Kai wrote: > One thing to worry about though is Linux distributions: We certainly don't > want to let them stick to an old Qt version because there are applications > still depending on qtquick1. However, a quick search with e.g. osc for > openSUSE shows that this shouldn't be a big problem

Re: [Development] Qt 5.4.2 "RC" packages available for your testing

2015-05-18 Thread Koehne Kai
> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > project.org [mailto:development- > bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of > Roland Winklmeier > Sent: Monday, May 18, 2015 3:24 PM > To: Heikkinen Jani > Cc: development@qt-project

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

2015-05-18 Thread Julien Blanc
On 18/05/2015 15:30, Andreas Aardal Hanssen wrote: 2015-05-18 14:56 GMT+02:00 Alejandro Exojo >: 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.

Re: [Development] Qt 5.4.2 "RC" packages available for your testing

2015-05-18 Thread Florian Bruhin
* Roland Winklmeier [2015-05-18 15:24:02 +0200]: > Hi All, > > I was trying to install the Qt 5.4.2 mingw491 RC package > (qt-opensource-windows-x86-mingw491_opengl-5.4.2_2015-05-04_23-23-12-132.exe) > but the installation failed. See attached screenshot (Unfortunately its > German Language - I d

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 14:56 GMT+02:00 Alejandro Exojo : > 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.

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

2015-05-18 Thread 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 m

Re: [Development] Call for Papers to Qt World Summit now open

2015-05-18 Thread Kojo Tero
Hello, A reminder on the Qt World Summit call for papers. This year the following topics are of special interest: * Creating Connected Devices and Internet of Things systems * Qt as the software solution for multi-platform development - desktop, mobile and embedded * Industrial and automotive HM

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

2015-05-18 Thread Alejandro Exojo
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 argu

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

2015-05-18 Thread Giuseppe D'Angelo
On Mon, May 18, 2015 at 12:54 PM, Al-Khanji Louai wrote: > Ooh, a bike shed thread! Indeed, trying to put the thread back on track: +1 for removing the overload (readLineInto or so). -- Giuseppe D'Angelo ___ Development mailing list Development@qt-

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

2015-05-18 Thread Al-Khanji Louai
> -Original Message- > From: development-bounces+louai.al-khanji=theqtcompany.com@qt- > project.org [mailto:development-bounces+louai.al- > khanji=theqtcompany@qt-project.org] On Behalf Of Marc Mutz > Sent: Monday, May 18, 2015 2:47 PM > To: development@qt-project.org > Subject: Re: [De

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

2015-05-18 Thread 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 on behalf of Andreas Aardal Hanssen Sent: Monday, May 18, 2015 12:10 PM To:

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 13:46 GMT+02:00 Marc Mutz : > On Monday 18 May 2015 12:17:32 Koehne Kai wrote: > > Can you elaborate? We're talking about in/out parameters here, where > > raw pointers IMO are still perfectly valid. What do you expect the > > signature of readLine(QString *line) to be in C++14? > QStr

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

2015-05-18 Thread Marc Mutz
On Monday 18 May 2015 12:17:32 Koehne Kai wrote: > Can you elaborate? We're talking about in/out parameters here, where > raw pointers IMO are still perfectly valid. What do you expect the > signature of readLine(QString *line) to be in C++14? QString readLine(QString &&reuseThisStringsCapacity);

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

2015-05-18 Thread Koehne Kai
> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > project.org [mailto:development- > bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of > Julien Blanc > Sent: Monday, May 18, 2015 12:08 PM > To: development@qt-project.org > Subject: Re: [Deve

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 12:07 GMT+02:00 Julien Blanc : > C++, you should resort to const-correctness to prevent mistakes. I like > There is no const correctness in C++. #dontfeedthetroll #trymakingaconstcorrectlinkedlistinc++ -- Andreas Aardal Hanssen ___ Developm

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 11:54 GMT+02:00 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.

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

2015-05-18 Thread Julien Blanc
On 17/05/2015 15:19, Giuseppe D'Angelo wrote: > On Sun, May 17, 2015 at 2:30 PM, Andre Somers wrote: >> In the spirit of option b), would it be an option to have the method >> take a QString& instead of a QString*? That would resolve the ambiguity. > It would solve, but Qt APIs use pointers instea

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

2015-05-18 Thread 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 i

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 11:40 GMT+02:00 André Somers : > 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 b

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

2015-05-18 Thread André Somers
Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35: 2015-05-18 11:10 GMT+02:00 Christian Kandeler >: On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: > On Sun, May 17, 2015 at 9:55 PM, Smith Martin > mailto:martin.sm...@theqtcompany.com>

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

2015-05-18 Thread Andreas Aardal Hanssen
2015-05-18 11:10 GMT+02:00 Christian Kandeler < christian.kande...@theqtcompany.com>: > On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: > > On Sun, May 17, 2015 at 9:55 PM, Smith Martin > > wrote: > >> How do you get bitten by an out-reference? > > As usual, because at call site I didn't realize

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

2015-05-18 Thread Christian Kandeler
On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: > On Sun, May 17, 2015 at 9:55 PM, Smith Martin > 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); >

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

2015-05-18 Thread André Somers
Giuseppe D'Angelo schreef op 17-5-2015 om 21:57: > On Sun, May 17, 2015 at 9:55 PM, Smith Martin > 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); > d

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

2015-05-18 Thread Simon Hausmann
On Sunday, May 17, 2015 12:21:35 PM Thiago Macieira wrote: > On Sunday 17 May 2015 22:17:04 Marc Mutz wrote: > > On Sunday 17 May 2015 15:19:49 Giuseppe D'Angelo wrote: > > > It would solve, but Qt APIs use pointers instead of references for > > > out-arguments (and that's a very good code policy).