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

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.  Here's a hypothetical example of where that might be nice:

void myFunc(int foo) {
   foreach(i, 0..1_000_000) {
       if(foo < 5) {  //This is an unusual case, foo usually >5.
          bar(foo);
       }
       //Stuff that may change the value of foo.
   }
   //More stuff that may change the value of foo.
   foreach(i; 0..1_000_000) {
       if(foo < 5) {  //Again unusual
           bar(foo);
       }
       //More stuff that may change the value of foo.
   }
}

In this case the compiler, not understanding the high-level meaning of what is being done, would likely not realize that foo is almost always >= 5 in real-world scenarios.  It would likely inline bar at both places it's called from, contributing to code bloat, especially since it's called from a loop that iterates a lot of times.  However, since the programmer knows that the branch that calls bar() will be taken very infrequently, the programmer might want to specify that bar() should not be inlined.

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.

Looking ahead, I think macro() will reduce the need for an inline specifier.  Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it.

--bb

dsimcha:
> In this case the compiler, not understanding the high-level meaning of what is being done, would likely not realize that foo is almost always >= 5 in real-world scenarios.

GCC has profile-guided optimization, that is often enough for the compiler to know what branch is the most frequent. In GCC there's the __builtin_expect() too for a similar purpose (if a branch calls a function rarely, the compiler understands it's probably not positive to inline it).

Bye,
bearophile

Bill Baxter 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.
> 
> Looking ahead, I think macro() will reduce the need for an inline specifier.  Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it.
> 
> --bb

The last thing I want from a language is two completely different methods that may require me to flip implementation methods for assumed gains from compiler optimizations.

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g5od1q$2v3b$3@digitalmars.com...
> 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.
>
> Looking ahead, I think macro() will reduce the need for an inline specifier.  Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it.
>
> --bb

Macros aren't coming until D3.

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

"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

Bill Baxter wrote:
> Looking ahead, I think macro() will reduce the need for an inline specifier.

I don't see the need for an inline or non-inline specifier. It's as obsolete as the register keyword. Does anyone have a non-trivial non-contrived benchmark where a difference is measurable?

"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.