[Qt-interest] Why Bus error clientSocket->waitForConnected()?

[Kustaa Nyholm]

>> Why? Who needs a non blocking readline? Like I've already said several
>> times I would love to see a use case where this is needed...
> 
> Because none of the QIODevice API is blocking, except for the waitFor
> functions.

Yes, I got that a long time ago, how about the use case?

> 
> The design principle is that you can call any function and expect it to return
> immediately. That makes the API usable from an event-driven application in the
> GUI thread, without worrying that the GUI might freeze because the socket
> hasn't received enough bytes.

So that [you can call any function and expect it to return immediately] is
the overriding design consideration? Ok, this explains it, so it was just
that readLine() design was hostage to this consideration?

> Please stop reading Qt 3.3 documentation. It's irrelevant.

Sorry, I presumed that this would have been unchanged from version
to version in the name of backwards compatibility. I'm actually using Qt 4.7
but routinely google for the API docs as I find it easier than using
the Qt documentation and in my laziness I did not bother check the version.
> 
> However, Qt 3.3 had the behaviour I wanted it to have in Qt 4. It was changed
> in the 4.0 process and now we have to live with it.

Are you going to change this back?


> 
>> So it does not return the last line at all if it is not new line
>> terminated?
> 
> It does in Qt 4.

Ok.

> 
> 
> The API design is perfectly good. The API is non-blocking and that was
> intentional.

Only as far as your design criteria [non-blocking API] is satisfied,
your users may feel and some actually do feel differently when it comes to
readLine(). 

Everyone is entitled to their opinion I guess.

> 
>>> canReadLine() will return true for as long as there's a line to be read.
>>> If the device, process or socket is closed without a newline at the end,
>>> canReadLine() will return false for that last chunk of data. But
>>> readLine() will return it.
>> 
>> According to the documentation this is not so, but regardless, how
>> is this API proposed to be used?
>> 
>> With Java API design I would do something like:
>> 
>>         while (null != (line = reader.readLine()))
>>             processLine( line );
> 
> If the device is a file or all data is available (such as a closed socket,
> finished process or finished QNetworkReply):
>     QByteArray line;
>     while (!(line  = device.readLine()).isNull())
>         processLine(line);

For that to work, I as a coder, need to know and care if it is a file
or close socket or what have you ... doesn't sound good. Surely I
should be able to write code for something as simple as this that does
not need to care. 

But I see that below you have a better example for the blocking case so
let's move on.

> 
> Or if you insist in doing it the blocking way:

Well, that was the requirement in the OP's problem and in
many cases that makes perfect sense.

> 
>     while (device.waitForReadyRead(-1)) {
>         while (device.canReadLine())
>             processLine(device.readLine());
>     }
>     if (device.bytesAvailable())
>         processLine(device.readLine()); /* device finished without a newline
>

Ok, more or less what I sketched, and demonstrates the main issue of
having a non blocking readLine() in that the processLine needs to be
presented twice preventing coding of that processing
in-line unless I want to copy/paste the code. Not a big deal,
but shows that from the readLine() point of view the API design
leaves something to desire for, but I know understand that Qt's
overall design goal is/was non blocking API.

Fair enough.


>> First I have several issues with the waitForMore documentation, which
>> says:
<SNIP>
> 
> Please stop reading Qt 3.3 documentation. It's waitForReadyRead in Qt 4.
> 

Ok, I see that the problems with 3.3 documentation have been mostly
fixed in Qt 4 API docs. Great.

>> The code also  begs the question how waitForMore is implemented internally,
>> ie what happens when some bytes are available but canReadLine returns false
>> and thus readLine will not be called to consume them?
> 
> waitForReadyRead() waits for more bytes to become available, regardless of
> whether there are bytes already available for reading.
> 

Good, Qt 4 docs makes this clear whereas 3.3 was rather vague about this.

>> But I have very little practical Qt experience yet, so maybe some one
>> shows how this is supposed to done in Qt?
> 
> See above. And please upgrade to Qt 4.6.

Thanks, and I'm actually using 4.7, I was not aware that there were this
kind of upwards [readLine() behaviour changes] compatibility issues in Qt.

thanks Kusti