Re: kernel-2.2.1-undefined references.

["Bryan W. Headley" <bheadley at interaccess dot com>]

Ross Smith wrote:

> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer.  That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >Note you have a rather atypical perspective.  You know the hardware
> >in depth, and you know which instruction sequences will be faster.
> >You probably know (or at least can make an informed guess) if inline
> >will help or hinder the code.  You also sometimes need precise control
> >over low-level code.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
>   (A) inline == "I [the programmer] know exactly what this code is
>   supposed to do at low level, and I have determined that this function
>   must be inline for proper behaviour, so inline it or give me an error
>   if you [the compiler] can't."
>
>   (B) inline == "I [the programmer] believe this code would be more
>   efficient if this function were expanded inline, so please do so
>   unless you [the compiler] have a good reason to do otherwise."
>
> Linus wants (A), but the inline keyword, as defined by ISO C++,
> mandates (B). Exactly what consitutes a "good reason" is a function of
> compiler technology. In many cases, compilers *are* smarter (about
> certain specific things) than programmers, and will quite rightly
> override the programmer's choice. For inline, this is rare today, but
> will get more common until eventually "inline" goes the way of
> "register".
>

No, I heard more than that. Such as, the compiler may opt to make a function
into an inline based on optimization. Which scares the hell out of me, too.

The argument, though, should be telling you that basing a C compiler
front-end on top of a C++ engine is going to become more and more risky.
There once was a time when there was a tight correlation between the C code
and the assembly. With C++, with "hidden" destructors to deal with exception
handling, jump tables to give the feel of class heirarchy, etc., you cannot
say that anymore.

I like Per's comments about not being able to produce a compiler that behaves
like Linus would want. It sort of makes Messrs Kernighan, Richie and Thompson
just a little bit more special than they are already :-)

#include <bryan/has/little/respect/for/ansi/nor/iso/as/they/are/usually/10/years/behind>

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com