std.socket classes

[Jonathan Marler via Digitalmars-d-learn]

On Sunday, 9 April 2017 at 15:04:29 UTC, rikki cattermole wrote:
> On 09/04/2017 3:56 PM, Jonathan Marler wrote:
>> On Sunday, 9 April 2017 at 14:49:14 UTC, rikki cattermole 
>> wrote:
>>> Don't think too hard, times have changed since std.socket was 
>>> written.
>>> It certainly isn't designed for high performance hence e.g. 
>>> libasync.
>>
>> What an odd response... You don't think I should ask questions 
>> about why
>> decisions were made?  If I took that approach how would I 
>> learn?  And if
>> you discourage other people from asking questions by telling 
>> them they
>> are "thinking too hard" what kind of effect does that have on 
>> the
>> community?
>>
>> As for "high performance", my questions have less to do with 
>> performance
>> than they do with an API that makes sense and doesn't feel 
>> "kludgy".
>
> Oh sorry, I had a brain derp and thought at the end there you 
> had that you thought about it and it didn't make sense. Hence 
> the slightly weirder response.

Ah ok.  That response was surprising to me coming from you (based 
on what I've read from you in the past) but I see it was a 
misunderstanding.

>
> What I meant is that, for common use cases it works well enough 
> and it does use reasonably sound API even if a bit cludgy.
>
> When asking about classes, one of the big things is the vtable. 
> They are slow (compared to final classes and structs). This is 
> the main reason people want to switch over to structs instead 
> of classes. However if you take a look at the more performance 
> aware libraries like libasync you will see classes used 
> extensively still.
>
> Here is my suggestion, its a little harder to toy with ideas 
> without real code to show for it. All our more existing API's 
> are mostly class based for high performance sockets, timers 
> ext. So, would you like to have a go and explore this area 
> since we are playing it a bit too safe for your liking?

What I've found myself having to do is use the lower level 
platform specific APIs that use socket_t and sockaddr, but then I 
get platform dependencies and can't access alot of the library 
because it requires the higher level Socket and Address objects.  
I would be willing to explore this area, but before I do work in 
an area I research what's already been done.  Hence why I'm 
asking the questions about why it was done this way in the first 
place.  For all I know there are very good reasons it was done 
this way that I just don't know about.