superdan wrote:
> before you say, "but value vs. 'in' is entirely transparent to the user", let
> me note that aliasing is going to fuck that plan right there.
> 
> deciding value vs. reference only works for invariant shit. it's in fact part
> of why invariant shit is so fucking brilliant.

If it's a const reference, aliasing doesn't matter, no? Or am I missing something about D2's latest const system (quite possible)? One should only be reading from a const ref so it's semantically equivalent to just 'in'.

'inout' should still be there, with reasonable aliasing restrictions.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Matti Niemenmaa wrote:
> superdan wrote:
>> before you say, "but value vs. 'in' is entirely transparent to the user", let
>> me note that aliasing is going to fuck that plan right there.
>>
>> deciding value vs. reference only works for invariant shit. it's in fact part
>> of why invariant shit is so fucking brilliant.
> 
> If it's a const reference, aliasing doesn't matter, no? Or am I missing something about D2's latest const system (quite possible)? One should only be reading from a const ref so it's semantically equivalent to just 'in'.

It would have to be an invariant ref, not a const ref, for aliasing to not matter.

> 
> 'inout' should still be there, with reasonable aliasing restrictions.
> 

Don wrote:
> JAnderson wrote:
>> JAnderson wrote:
>>> bobef wrote:
>>>> This has probably been asked many times before. If someone knows of such discussion please paste me a link. Why not an 'inline' attribute? We all know that the compiler can be stupid some times, and even if it is not people may want to inline something that is normally not appropriate for inlining. Auto inlining is fine, but people should have control over such kind of things I believe.
>>>>
>>>> Regards, bobef
>>>
>>> May C++ compilers ignore the inline attribute because it has a better handle on when to inline.  There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer.
>>>
>>> But that's C++.  D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice.
>>>
>>> -Joel
>>
>> I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow.  So I placed a few inlines around and *bam* that code started running faster.  Then I profiled the code as a whole to see how much of an improvement I'd gained.  However the game was actually running slower.  It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time.
>>
>> I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse.
>>
>> -Joel
> 
> Yup. Code cache can easily become a bottleneck. Similarly, turning on 'optimise for speed' for a whole program is almost always a bad idea.

I've had some good results with whole program optimisation.  However not always.

> 
> More useful than 'inline', would be some way to tell the compiler 'this function is speed-critical'. If nothing else, it would have some documentation value.

I think that's a good idea.  The compiler could also spin more cycles to optimize that piece of code.

-Joel

Nick Sabalausky wrote:
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:g5p23e$2iue$1@digitalmars.com...
>> "dsimcha" wrote
>>> If we're going to make the jump and expose these features to the programmer, a
>>> noinline attribute to do the opposite might be nice also.
>> Although a noinline directive would be ideal, it is technically possible to force non-inlining of functions by using D interface files (.di) to define the functions as prototypes, and only compile the real code in an object file.  But that's a lot of work compared to just tagging the function.
>>
>> Forcing inlining, on the other hand, is impossible currently.
>>
>> -Steve
> 
> You could write it as a string mixin. 
> 
> 

What about using a template?  Wouldn't that encourage the compiler to inline?

-Joel