On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
On 8 June 2013 13:25, Walter Bright
<newshou...@digitalmars.com> wrote:
On 6/7/2013 5:15 PM, Manu wrote:
I can tell you that in my case, we export a lot(/most)
things. Renderer
api,
sound api, etc are often all in their own libraries. So none
of them are
ever
eligible for optimisation.
I'm curious why these exports all must be classes, and cannot
be structs?
Because they embody functionality, not just data. That's just
how many many
programmers write code.
Go to university for a couple of years, see what they tell
you... ;)
Some of these systems can effectively be considered plugins.
Consider
OpenGL/DirectX? DirectSound/XAudio? Linux has a million
back-end API's to
choose from.
I can see why many people feel it's natural to design their
API's/systems
that way, right or wrong.
I don't agree with it personally, I would write it differently,
but I'll
never win that argument. Tech/systems programmers are vastly
outnumbered in
most studios. And of course, most programmers are junior-mid
experience,
that's just commercial reality.
Personally, I never understood why portability must pass by a
plugin architecture. In our game engine we use macro to build the
right implementation depending on the target platform and pure
interfaces to be sure that API are respected.
It's not an issue, because the user don't have to be able to
choose the sound backend, and developer can do it for testing but
it requires a full rebuild (a real issue due to the C++ slow
compilation).
