
Originally Posted by
erqsor
As I said at begining, I have some problems :
- Inherit the QWsServer from QTcpServer : I can't because the newConnection signal is already used in background by the QTcpServer. And I can't offer this signal to the QWsServer users by inheritance.
- Inherit the QWsSocket from QTcpSocket : I can't for the same reason with the readyRead signal.
So I have not used inheritance, but aggregation (I don't know if thats the right word in English). So the QWsServer has a ptr to a QTcpServer as member. And the QWsSocket has a QTcpSocket ptr as member too.
QWsServer inherits from QObject and QWsSocket inherits from QAbstratSocket.
And finaly, for now I created my own signals and fonctions to read data in a QWsSocket, but I wanted to use the QAbstractSocket features to the fullest, and so reimplementing the common read functions and signals.
That's all ok however in my opinion there is just no point in deriving your QWsSocket from QAbstractSocket. QIODevice would do just fine and you could reimplement only those methods you really needed (unfortunately not only the two you mentioned in the beginning).
And here is why I think the way I think... Unless you want to implement the client side as well, your QWsSocket won't sanely implement the following methods from QAbstractSocket:
void connectToHost
( const QString & hostName, quint16 port, OpenMode openMode
= ReadWrite
) void connectToHost
( const QHostAddress & address, quint16 port, OpenMode openMode
= ReadWrite
) bool waitForConnected ( int msecs = 30000 )
bool waitForDisconnected ( int msecs = 30000 )
void connectToHost ( const QString & hostName, quint16 port, OpenMode openMode = ReadWrite )
void connectToHost ( const QHostAddress & address, quint16 port, OpenMode openMode = ReadWrite )
QNetworkProxy proxy () const
void setProxy ( const QNetworkProxy & networkProxy )
bool waitForConnected ( int msecs = 30000 )
bool waitForDisconnected ( int msecs = 30000 )
To copy to clipboard, switch view to plain text mode
So what is the point in having those methods around?
Correct me if I'm wrong, but what your users need is:
read()
write()
close()
bytesAvailable()
signal readyRead()
signal bytesWritten()
quint16 peerPort()
read()
write()
close()
bytesAvailable()
signal readyRead()
signal bytesWritten()
QHostAddress peerAddress()
quint16 peerPort()
To copy to clipboard, switch view to plain text mode
Apart from the last two methods the rest is defined in QIODevice. So you are leaving 6 dangling methods just for the benefit of having other two methods that are pretty simple to implement.
A potential advantage of subclassing QAbstractSocket would be if someone wanted to replace one socket implementation for another. Unfortunately protocols differ so much that in 99% of the cases it is just not possible (and where it is possible, you can just use QIODevice API). So what is the point of deriving from QAbstractSocket?
Bookmarks