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

Smith Martin Martin.Smith at theqtcompany.com
Mon May 18 11:54:31 CEST 2015

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.


From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Andreas Aardal Hanssen <andreas at 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 <andre at familiesomers.nl<mailto:andre at 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 Aardal Hanssen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150518/056ce80c/attachment.html>

More information about the Development mailing list