<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 March 2014 16:39, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<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">On 3/12/2014 11:44 PM, Manu wrote:<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">
But you understand the danger in creating a situation where experts can't<br>
optimise their code even if they want to; if at some later time it becomes an<br>
issue, or some new customer comes along with more stringent requirements.<br>
These are not unrealistic hypothetical scenarios. Libraries exist, and they have<br>
customers by definition. Requirements change over time. Defaulting to an<br>
inflexible position is dangerous.<br>
</blockquote>
<br>
As I pointed out in another post, virtuality is hardly the only thing that can change in an interface that strongly affects performance. The existence of destructors is another. About everything about an interface affects performance.<br>
</blockquote><div><br></div><div>In my experience, API layout is the sort of performance detail that library authors are much more likely to carefully consider and get right. It's higher level, easier to understand, and affects all architectures equally.</div>
<div>It's also something that they teach in uni. People write books about that sort of thing.</div><div>Not to say there aren't terrible API designs out there, but D doesn't make terrible-api-design-by-default a feature.</div>
<div>Stuff like virtual is the sort of thing that only gets addressed when it is reported by a user that cares, and library authors are terribly reluctant to implement a breaking change because some user reported it. I know this from experience.</div>
<div>I can say with confidence, poor API design has caused me less problems than virtual in my career.</div><div><br></div><div>Can you honestly tell me that you truly believe that library authors will consider, as a matter of common sense, the implications of virtual (the silent default state) in their api?</div>
<div>Do you truly believe that I'm making a big deal out of nothing; that I will never actually, in practise, encounter trivial accessors and properties that can't inline appearing in my hot loops, or other related issues.</div>
<div><br></div><div>Inline-ability is a very strong API level performance influence, especially in a language with properties.</div><div><br></div><div>Most programmers are not low-level experts, they don't know how to protect themselves from this sort of thing. Honestly, almost everyone will just stick with the default.</div>
</div></div></div>