std.socket classes

[Jonathan Marler via Digitalmars-d-learn]

On Monday, 10 April 2017 at 18:57:13 UTC, Adam D. Ruppe wrote:
> On Monday, 10 April 2017 at 16:18:20 UTC, Jonathan Marler wrote:
>> An interesting benefit. However, I don't think this is the 
>> ideal way to support such a use case.
>
> If I was doing it myself, I'd probably do an interface / final 
> class split too (which also opens up a wee bit of additional 
> easy optimization), but the Socket class isn't *bad* for this.

Yeah I agree, not perfect but not *bad*.

>
>
>> My first thought is that since the interface you are using 
>> (the Socket class) wasn't really designed to be overridden, 
>> you probably had to do some interesting hacks to make it work.
>
>
> No, the code is very straight-forward, regular class method 
> overrides with appropriate forwards to the base class 
> implementation where needed.
>
>>  For example, when you accept a new socket, you probably had 
>> to delete the Socket object you got and create a new SSLSocket 
>> object passing the handle from one to the other, and make sure
>
> I didn't implement the server, but if I did, it would be 
> another simple case of
>
> override SslSocket accept() {
>    return new SslSocket(....);
> }
>
> or better yet, `override SslSocket accepting() { ...}`, since 
> there IS a method specifically designed for this:
>
> http://dpldocs.info/experimental-docs/std.socket.Socket.accepting.html
>
> That'd work fine too.

Ah, it seems someone already ran into this accept problem, hence 
why the new "accepting" function was added. Funny timing that 
this was added near the time I asked the question.

Since my last post I've been looking through std.socket and I see 
quite a bit of inefficiency especially when it comes to GC 
memory.  I think moving forward the best solution for me is to 
use my version of std.socket. It would also be great if Walter's 
new ref-counted exceptions proposal gets implemented soon because 
then I could make it @nogc.  Anyway, thanks for the feedback.