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.
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?
