|
|
Buffered I/O
This abstract class implements basic functionality for buffered input/output.
Through the available methods, you can find out how many bytes are available for reading, how many are still unsent and you can peek at the buffered data.
This class was intentionally written to resemble QSocket, because KExtendedSocket is a subclass of this one. This is so that applications written using QSocket's buffering characteristics will be more easily ported to the more powerful KExtendedSocket class.
KBufferedIO already provides a powerful internal buffering algorithm. However, this does not include the I/O itself, which must be implemented in derived classes. Thus, to implement a class that does some I/O, you must override, in addition to the pure virtual QIODevice methods, these three:
If your derived class reimplements the buffering algorithm, you must then decide which buffering functions to override. For instance, you may want to change the protected functions like feedReadBuffer and consumeReadBuffer.
KBufferedIO ()
| KBufferedIO |
[protected]
enum closeModes { availRead = 0x01, dirtyWrite = 0x02, involuntary = 0x10, delayed = 0x20, closedNow = 0x40 } | closeModes |
The modes for closed() signal
~KBufferedIO ()
| ~KBufferedIO |
[virtual]
Destroys this class. The flushing of the buffers is implementation dependant. The default implementation discards the contents
void closeNow ()
| closeNow |
[pure virtual]
Closes the stream now, discarding the contents of the write buffer. That is, we won't try to flush that buffer before closing. If you want that buffer to be flushed, you can call flush, which is blocking, and then closeNow, or you can call close for a delayed close.
bool setBufferSize (int rsize, int wsize = -2)
| setBufferSize |
[virtual]
Sets the internal buffer size to value. Not all implementations support this. The parameters may be 0 to make the class unbuffered or -1 to let the class choose the size, which may be unlimited or -2 to leave the buffer size untouched. Note that setting the write buffer size to any value smaller than the current size of the buffer will force it to flush first, which can make this call blocking. Returns true if setting both was ok. If false is returned, the buffers were left unchanged.
The default implementation does not support setting the buffer sizes. You can only call this function with values -1 for "don't care" or -2 for "unchanged"
Parameters:
rsize | the size of the read buffer |
wsize | the size of the write buffer |
int bytesAvailable ()
| bytesAvailable |
[const virtual]
Returns the number of bytes available for reading in the read buffer
int waitForMore (int msec)
| waitForMore |
[pure virtual]
Waits for more data to be available and returns the amount of available data then. Returns -1 if we cannot wait (e.g., that doesn't make sense in this stream)
Parameters:
msec | number of milliseconds to wait, -1 to wait forever |
int bytesToWrite ()
| bytesToWrite |
[const virtual]
Returns the number of bytes yet to write, still in the write buffer
bool canReadLine ()
| canReadLine |
[const virtual]
Returns true when there is enough data in the buffer to read a line
The default implementation reads directly from inBuf, so if your implementation changes the meaning of that member, then you must override this function.
int peekBlock (char *data, uint maxlen)
| peekBlock |
[pure virtual]
Reads into the user buffer at most maxlen bytes, but does not consume that data from the read buffer. This is useful to check whether we already have the needed data to process something. This function may want to try and read more data from the system provided it won't block. Returns the number of bytes actually copied.
Parameters:
data | the user buffer pointer, at least maxlen bytes long |
maxlen | the maximum length to be peeked |
int unreadBlock (const char *data, uint len)
| unreadBlock |
[virtual]
Unreads some data. That is, write the data to the beginning of the read buffer, so that next calls to readBlock or peekBlock will see this data instead. Note not all devices implement this since this could mean a semantic problem. For instance, sockets are sequential devices, so they won't accept unreading.
Parameters:
data | the data to be unread |
size | the size of the data |
void bytesWritten (int nbytes)
| bytesWritten |
[signal]
This signal gets sent whenever bytes are written from the buffer.
void closed (int state)
| closed |
[signal]
This signal gets sent when the stream is closed. The state
parameter
will give the current state, in OR-ed bits:
availRead read buffer contains data to be read
dirtyWrite write buffer wasn't empty when the stream closed
involuntary the stream wasn't closed due to user request
(i.e., call to close). Probably remote end closed it
delayed the stream was closed voluntarily by the user, but it
happened only after the write buffer was emptied
closedNow the stream was closed voluntarily by the user, by
explicitly calling closeNow, which means the
write buffer's contents may have been discarded