Chaining QIODevice Instances

[wswartzendruber]

Is it customary in Qt4 to chain QIODevice-derived instances together?

In .NET, we can chain streams together so that operating on one affects the rest.

CryptoStream >> GZipStream >> NetworkStream

Calling Write() on the CryptoStream would push the data through the GZipStream and then on through to the NetworkStream. Such is the way of doing things in the .NET world.

Is this customary in Qt4 with QIODevice-based classes?

[wysota]

Qt only implements a single layer of devices. In other words, chaining existing QIODevice classes wouldn't make any sense. But it is possible (and actually used) to provide chaining mechanism for your own custom QIODevice. I once implemented an RC4 QIODevice that could be chained with any other QIODevice.

[wswartzendruber]

Qt only implements a single layer of devices. In other words, chaining existing QIODevice classes wouldn't make any sense. But it is possible (and actually used) to provide chaining mechanism for your own custom QIODevice. I once implemented an RC4 QIODevice that could be chained with any other QIODevice.
I'm asking because I wrote a randomized encryption wrapper using .NET. The main class inherits the .NET Stream class. One of the constructor parameters is the stream you want to read plaintext from or write ciphertext to. Is this kosher with Qt4? I don't know exactly what type of chaining you did with your class.

[wysota]

I'm sure the interfaces between Qt4 and .NET are not compatible. The concept of "stream" or "device" might be different (In Qt the device doesn't have to be a stream).

My class worked similar to what you describe. The device was set using a dedicated method instead of the constructor, though.

[wswartzendruber]

Here's a question: Why does QProcess provide both setStandardOutputFile and setStandardOutputProcess instead of just setStandardOutputIODevice? That way we could set a process to send its standard output to a QBuffer, a QTcpSocket, or anything that inherits QIODevice. QProcess itself inherits QIODevice.

[wysota]

Because this functionality would have been probably used once per millenium. But feel free to suggest an improvement to QtSoftware, implementing it would probably take just a few minutes.

[wswartzendruber]

Because this functionality would have been probably used once per millenium. But feel free to suggest an improvement to QtSoftware, implementing it would probably take just a few minutes.
I put that bug report in to Qt Software. I justified the suggestion by saying we could pipe stdout from one QProcess through a pair of QTcpSockets and then to stdin of a QProcess on a completely different machine.

:p

[wysota]

You can do that even now with additional 4 lines of code (QProcess is a QIODevice itself). So the question remains - is it worth the effort.

[wswartzendruber]

You can do that even now with additional 4 lines of code (QProcess is a QIODevice itself). So the question remains - is it worth the effort.
Can I get that code?

[wysota]

Can I get that code?

Two connect statements on either side of the network link plus two one line slots triggered upon readyRead() signals reading the available content from one device and pushing it to the other (process->socket and socket->process).