Writing custom QIODevice with 2 channels

[high_flyer]

Umm...
Based on your code, there is no need to sublcass QIODevice, since you are doing nothing that the current QTcpSockets are not doing (QTcpSocket is a QIODevice).
You detector class can be a simple QObject, which basically managers the the reading and writing to your two sockets (which is basically what your code appears to be trying to do).
Line 37 in your code simply is not needed and is doing nothing of value.
This way you don't have to implement the virtuals of QIOdevice and you can mold your API as you need it.

[notfound404]

First of all thank you for your reply. Much appreciated.

Based on your code, there is no need to subcass QIODevice, since you are doing nothing that the current QTcpSockets are not doing (QTcpSocket is a QIODevice). You detector class can be a simple QObject...

I agree that looking at my code there is no need for that, but I do want to extend my custom object, so that I will be able to take advantage of many other funcionalities of QIODevice, like for example being able to use QDataStream, which in constructor takes QIODevice. Moreover I would like to make my application very easy to reuse, by just replacing my custom QIODevice object to any other QIODevice object when it would be necessary.

Line 37 in your code simply is not needed and is doing nothing of value.

Yes, for now I am not using it, however it is setting some variables (Readonly / Writeonly) which I can check later on, in for example read / write methods to made them work corectly.

And one more thing, why QT made such a beautiful class as QIODevice with support for multichannel communication when as far as I know no other QT object that is inheriting from it is using those channels?

[high_flyer]

I agree that looking at my code there is no need for that, but I do want to extend my custom object, so that I will be able to take advantage of many other funcionalities of QIODevice, like for example being able to use QDataStream, which in constructor takes QIODevice. Moreover I would like to make my application very easy to reuse, by just replacing my custom QIODevice object to any other QIODevice object when it would be necessary.

Again, you CAN take advantage of these features by calling them on your QTcpSocket.

Yes, for now I am not using it, however it is setting some variables (Readonly / Writeonly) which I can check later on, in for example read / write methods to made them work corectly.

And one more thing, why QT made such a beautiful class as QIODevice with support for multichannel communication when as far as I know no other QT object that is inheriting from it is using those channels?

Its sound to me you do not fully understand what subclassing is used for.
Qt offers QIODevice for people to be able to write new QIODevices and to have an "interface" class to all QIODevices that are already implemented by Qt, this is what OOP is all about.
That means if you have a new type of hardware that needs different implementation of writing, reading etc, then you can implement it in a way that will conform to QIODevice and allow you to use it with other Qt QIODevice consumer classes.
This is however NOT what you are doing.
You are fully content with using the functionality offered by QTcpSocket. (Based on the posted code).
You don't need a new low level implementation of the socket, you simply have a case where you need to coordinate between two sockets - that is NOT a new device, that is simply a manager class.