"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:alk75k$1noo$1@digitaldaemon.com...
> It's a fault of the language, because that it's unspecified behavior.  The inline keyword is merely a suggestion.

The language specifies a certain semantic meaning, which should be the same regardless of whether inlining happens or not.

> I want an inline keyword with the meaning "inline this or give me one good reason why you can't, as a warning".  That permits platform specific behavior but is easier to manage.  Eliminates lots of guesswork.

As compilers improve, this issue should become completely moot. Also, I expect most D compilers to be based on the open D source, which implements inlining and so should provide that as a minimum.

When I profile code, I always wind up disassembling the bottlenecks anyway to see if there is some unexpected inefficient code being generated. I'm not convinced that one can write high performance code in a high level language without knowing the corresponding machine code. For example, I know a fellow who wrote his first program, a program to write some strings out to a file. For each character, he opened the file, appended the character, and closed the file. It ran fantastically slowly, of course. He asked a friend to examine his code and tell him why it was so slow. When it was explained, he replied that the manuals for the file I/O functions said nothing at all about how to do efficient file I/O or the tradeoffs involved. He was right.

Analogously, to write high performance code, you'll need to get familiar with how your particular compiler generates code for particular language constructs. No way around it - and you can certainly find yourself implementing the same algorithm in different ways for different compilers/systems due to different ways code is generated.

Inlining is only one part of a much larger code generation issue, such as register allocation, addressing modes, instruction scheduling, etc., all interacting with each other.

It is a good idea to have some kind of slider that changes optimization between size and speed, but that such should be on a per-module basis. A higher desired speed / size ratio would cause the compiler to do more aggressive inlining.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:alk82e$1olk$1@digitaldaemon.com...
> Yeah and now we have the need for the "volatile" keyword.  ;)  To tell the compiler to not enregister a variable.

That one's going on in another thread at the moment <g>.

> Ignoring potentially important hints doesn't seem very smart, to me.  At least with volatile usually the language has to commit to some behavior,
has
> to give you some guarantee.  The inline hint can have any effect from
doing
> it to not doing it, to maybe having done it, to warning you about it, or not; a large range, and no guarantees.
>
> I can give you one damn good reason for not inlining automatically... it makes a module link-dependent on another module it uses inline functions from.  It increases coupling.  From a security standpoint it gives out too much information.  It's really only appropriate for private classes within
a
> module, or if you absolutely must have speed at the expense of privacy and interdependence.

You're right. You can prevent inlining by not specifying functions being 'final' or by not specifying the body of the function in the import file.