std.socket is horrible.

Daniel Gibson metalcaedes at gmail.com
Sun Aug 22 17:29:12 PDT 2010


cemiller schrieb:
> Would the problems be resolved with the following changes?
> 
> 
> Add a Socket class constructor:
> this(socket_t sock, AddressFamily af)
> {
>     assert(sock != socket_t.init);
>     this.sock = sock;
>     this._family = af;
> }
> 

Yes, this constructor would be really helpful.

> Socket.newFamilyObject():
> This is currently private but can be made protected to allow overriding 
> to return new address types.

I stumbled upon this after sending my initial mail - yes, this should 
definitely be protected instead of private.

> 
> Address.name() and Address.nameLen():
> Is there a function you need to call with these? I suppose they can be 
> made public just in case they're needed elsewhere.
> 

The obvious case (I came across myself) is that one might want to derive 
Socket and override methods like bind.
Another thing is that you could just use the relatively 
high-level/painless Address-classes (like InternetAddress) to get such 
an Object and still pass the contained sockaddr to low-level functions 
that need it.
IMHO they should just be made public, I guess it won't do any harm ;)

> 
> As for things like _SOCKET_ERROR and _lasterr(), they're just simple 
> shortcuts to the low-level sockets. If you're working with the low-level 
> sockets, then you have access to what _SOCKET_ERROR and _lasterr() refer 
> to; otherwise, you don't need them.

I know, that's why I called it "minor stuff" - it really doesn't have to 
be exposed outside of std.socket.
It was mainly the fact that I couldn't set the socket_t of Socket and 
couldn't access Address.name() and Address.nameLen() outside of 
std.socket that annoyed me.


Considering that (if I'm not mistaken) you're the original author of 
that Code: Please don't take my rant personally, I guess you just didn't 
consider this weird stuff I'm doing when you were writing it - after all 
the Socket class is meant to be a higher level abstraction of sockets so 
it seems natural not to expose the internal socket handle.

Apart from these small issues (that can easily be fixed by the 
maintainer) the I find general interface of std.socket quite usable :-)

Cheers,
- Daniel


More information about the Digitalmars-d mailing list