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.
