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

Julien Blanc julien.blanc at nmc-company.com
Mon May 18 16:00:44 CEST 2015

On 18/05/2015 15:30, Andreas Aardal Hanssen wrote:
> 2015-05-18 14:56 GMT+02:00 Alejandro Exojo <suy at badopi.org 
> <mailto:suy at badopi.org>>:
>     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".
> Very true! In fact the "opposite API" to toInt() was chosen in 
> QIODevice::getChar() to ensure that even the extra line of testing for 
> OK on the client side could be eliminated. For toInt(), it's rare that 
> the output arg needs to be tested, but for QIODevice::getChar(), it's 
> the opposite.
> char ch;
> if (device->getChar(&ch)) {
>     // foo
> }
> http://doc.qt.io/qt-5/qiodevice.html#getChar
> Imagine reading code like this:
> char ch;
> if (device->getChar(ch)) {
>     // foo, wtf is ch for??
> }

Which is exactly what the standard lib does :

<http://en.cppreference.com/w/cpp/io/basic_istream/get>  (see overload 2)

Notice that instead of returning a boolean, the stream is returned, 
which is then converted to a bool for testing its validity.

See also :


So, this is common design as well, and does not seems to cause much 
trouble as long as the semantic of the operation is clear :).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150518/98fd61b0/attachment.html>

More information about the Development mailing list