<div dir="ltr">On 8 June 2013 21:27, Flamaros <span dir="ltr"><<a href="mailto:flamaros.xavier@gmail.com" target="_blank">flamaros.xavier@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 8 June 2013 13:25, Walter Bright <<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>> wrote:<br>
<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 6/7/2013 5:15 PM, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I can tell you that in my case, we export a lot(/most) things. Renderer<br>
api,<br>
sound api, etc are often all in their own libraries. So none of them are<br>
ever<br>
eligible for optimisation.<br>
<br>
</blockquote>
<br>
I'm curious why these exports all must be classes, and cannot be structs?<br>
<br>
</blockquote>
<br></div></div><div class="im">
Because they embody functionality, not just data. That's just how many many<br>
programmers write code.<br>
Go to university for a couple of years, see what they tell you... ;)<br>
Some of these systems can effectively be considered plugins. Consider<br>
OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to<br>
choose from.<br>
I can see why many people feel it's natural to design their API's/systems<br>
that way, right or wrong.<br>
<br>
I don't agree with it personally, I would write it differently, but I'll<br>
never win that argument. Tech/systems programmers are vastly outnumbered in<br>
most studios. And of course, most programmers are junior-mid experience,<br>
that's just commercial reality.<br>
</div></blockquote>
<br>
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.<br>

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).<br>
</blockquote></div><br></div><div class="gmail_extra" style>But you are aware that people write code that way?</div><div class="gmail_extra" style>I'm trying to represent the interests of an industry, not just myself. Anyone who rejects D because they perceive it doesn't meet their needs is a lost opportunity.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Here's some example game-dev type API's.</div><div class="gmail_extra"><a href="http://www.ogre3d.org/docs/api/html/namespaceOgre.html">http://www.ogre3d.org/docs/api/html/namespaceOgre.html</a><br>
</div><div class="gmail_extra"><a href="http://www.continuousphysics.com/Bullet/BulletFull/annotated.html">http://www.continuousphysics.com/Bullet/BulletFull/annotated.html</a><br></div><div class="gmail_extra" style>These aren't particularly aggressive libs, but they are public, so you can see the sort of API that's typical as an example. Count the occurrences of 'virtual'...</div>
<div class="gmail_extra" style>Note, the accessors almost never declare virtual, unless they are low-frequency classes, like 'Compositor', which is mostly virtual (gets hit once per frame).</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>The ones I'm most familiar with are naturally closed-source or proprietary. For instance, Havok, FMod, Morpheme, Unreal, etc... All C++, with careful application of 'virtual'.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Microsoft API's (DirectX, etc) are COM, which implies classes.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>People use classes. Classes are not optional. I'm not looking for workarounds or alternative solutions.</div>
<div class="gmail_extra" style>If we can't supply classes that people can use in more-or-less the same way they have been doing so for decades, they probably won't choose D.</div><div class="gmail_extra" style><br>
</div><div class="gmail_extra" style>If D does offer some superior alternative paradigms, given time, they might experiment and become comfortable with them eventually (prove to themselves it's solid and satisfies all their requirements). But they won't just take your word for it, and certainly not without a wealth of other successful examples in the industry.<br>
</div><div class="gmail_extra" style>Programmers that make the switch to D have already taken on enough risk in that first step alone. If they have to risk changing a decade of coding habits and conventions too (which involves retraining all the staff), how can any business ever realistically make the change?</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I'm here, and interested in D due mainly to it's immediate familiarity, as opposed to others like Rust for instance. I can actually envision a migration. It seems like it's possible... one step at a time.</div>
<div class="gmail_extra" style>...it's also compiled and binary compatible, which is obviously critical ;) .. (this is where C# fails, or everyone would already be on that wagon without question)</div></div>