KExtendedSocket oddities

Malte Starostik malte at
Fri Dec 13 18:10:02 GMT 2002


in my first attempt to use KExtendedSocket et al. I encountered a few things 
I'd like to discuss :-)
Hope it doesn't sound too harsh, it's just a first impression of this rather 
complex class.

* KSocketAddress inherits QObject, defines Q_OBJECT but doesn't have any
  signals nor slots nor does it use any QObject functionality AFAICS. This
  seems unneccessarily inefficient (in my situation I need to keep some
  hundred addresses). Also it makes KSocketAddress noncopyable, IMHO it would
  be nice to have a copyable, value-based class instead. Of course this would
  totally break BC

* KExtendedSocket of course inherits QObject...but: its ctors don't take a
  QObject* parent argument, so one cannot use QObject's nice auto-deletion
  feature :-(
  Adding overloads with such a parameter wouldn't break anything, would it?

* setBindXXX() doesn't work on passive sockets. This is clearly documented,
  yet it looks unnatural to me. In most cases when you bind a socket, it's a
  passive one. Took me a while to find out that a passive socket is bound to
  the address set with setHost() etc. instead. IMHO they should either be
  equivalent for passive sockets or exactly the other way round as now.

* setAddressReusable() does nothing when called before listen().
  But that means bind() is called before one gets a chance to set
  SO_REUSEADDR. Not sure if this is a problem, but I've always seen and
  used SO_REUSEADDR _before_ calling bind().

* service and host resolution works primarily on QString. The overloads that
  take a number for the port argument use QString::number() and then call the
  QString versions. Why is this? Isn't a simple htons() far cheaper than
  int => QString => resolution? :-) Same for IP addresses, okay here I can see
  this would get difficult wrt IPv6 support. Still, what about overloads that
  take an in_addr/in6_addr and skip any host resolution?

* It's possible to create datagram sockets, which is nice. But somehow
  KExtendedSocket lacks wrappers around sendto() and recvfrom() to
  actually use such a socket, getting info about a packet's source and all.

* One last minor thing: the enumerator names like streamSocket, passiveSocket
  begin with a lowercase letter which contradicts most if not all other enums
  in kdelibs.

short circuit; auto accident; static electricity; struct by_lightning;
double trouble; unsigned long letter; float valve; short pants; void check;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <>

More information about the kde-core-devel mailing list