Slow performance compared to C++, ideas?

Flamaros flamaros.xavier at gmail.com
Sat Jun 8 04:27:07 PDT 2013


On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
> On 8 June 2013 13:25, Walter Bright 
> <newshound2 at 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).


More information about the Digitalmars-d mailing list