<p><br>
On Feb 24, 2014 2:10 AM, "Walter Bright" <<a href="mailto:newshound2@digitalmars.com">newshound2@digitalmars.com</a>> wrote:<br>
><br>
> On 2/23/2014 5:45 PM, Brad Roberts wrote:<br>
>><br>
>> At this point, you're starting to argue that the entire DIP isn't relevant.  I<br>
>> agree with the majority that if you're going to have the directive, then it<br>
>> needs to be enforcement, not suggestion.<br>
><br>
><br>
> 1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code.<br>
><br>
> 2. Making it a hard requirement then means the user will have to put versioning in it. It becomes inherently non-portable. There is no way to predict what some other version of some other compiler on some other system will do.<br>

><br>
> 3. In the end, the compiler should make the decision. Inlining does not always result in faster code, as I pointed out in another post.<br>
><br>
> 4. I don't see that users really are asking for inlining or not. They are asking for the fastest code. As such, providing hints about usage frequencies are entirely appropriate. Micromanaging the method used is not so appropriate. After all, the reason one uses a compiler in the first place rather than assembler is to not micromanage the actual instructions.<br>

><br>
><br>
> Perhaps the lesson is the word 'inline' carries certain expectations with it, and the feature would be better positioned as something like:<br>
><br>
>     pragma(usage, often);<br>
>     pragma(usage, rare);</p>
<p>Also known as, hot and cold functions. </p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>