The following seems like a good subset of the QAbstractSocket interfaces that also makes sense for QLocalSocket
void abort () void disconnectFromHost () SocketError error () const bool flush () bool isValid () const qint64 readBufferSize () const void setReadBufferSize ( qint64 size ) bool setSocketDescriptor ( int socketDescriptor, SocketState socketState = ConnectedState, OpenMode openMode = ReadWrite ) int socketDescriptor () const SocketType socketType () const SocketState state () const bool waitForConnected ( int msecs = 30000 ) bool waitForDisconnected ( int msecs = 30000 ) The SocketError & SocketState enums have already similar values in both class SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could also be NamedPipeSocket ? ) The following signals could also be common (again, it's about using the same enums): void connected () void disconnected () void error ( QAbstractSocket::SocketError socketError ) void stateChanged ( QAbstractSocket::SocketState socketState ) I dont see how the connectTo* methods could be shared, and I don't think it would be a good idea to try to do so. Regards, Corentin. 2012/11/6 Thiago Macieira <thiago.macie...@intel.com>: > On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote: >> Someone below asked what the motivation is behind having a common abstract >> socket base class for all concrete socket types. The reason for this is it >> can significantly clean up client code. Currently if I want to handle >> different sockets generically (e.g., TCP vs. local), I have to jump through >> several hurdles: create my own wrapper class abstraction, maintain separate >> lists of objects, etc. A single, common base class would allow client code >> to use polymorphism to manage and use socket objects very easily. For >> instance, I could then have client code that defines a >> QList<QAbstractSocket*> and is able to connect, disconnect, write, read, >> etc. from the socket without having to know the concrete class type. >> >> I hope this helps explain why it would be very useful to have a common base >> socket class. > > It's very clear why you'd want to have a common base class, but you were not > concrete on the details. I want to know what methods from QAbstractSocket > and/or QLocalSocket would you like to see in this common base class, methods > that aren't in QIODevice. > > Or, asked from another angle: why you can't use QList<QIODevice *> in your > case above? You said disconnect, read, write, all of which you can do with > QIODevice (close() is virtual, the signals are in QIODevice). > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
