This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
On Mon, 8 Feb 1999, Mike Stump wrote: > > Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST) > > From: Linus Torvalds <torvalds@transmeta.com> > > > 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. > > Let me provide a counterpoint. In C++, it is common to have > templates. In templates, it is common to have lots of small, > sometimes, really small functions. Sometimes, programmers put > `inline' on them. The C++ standard says they `inline' by default on > those defined in the class body, this also is common. That's fine. I'm actually not asking that _all_ "inline" keywords actually be honoured, I'm asking that there be some way of forcing gcc to honour it, the way it used to do. In particular, "extern inline" has basically been documented to be a macro (some Clintonesque arguments to the contrary notwithstanding), and does not make sense to not inline - the documentation even says so. If I have to add an "extern" to force the inline, that's fine. Removing features without giving a reasonable way of doing the thing that gcc has successfully been doing for 8 years is not reasonable. Codifying the fact that if you really _rely_ on inlines, do so with an "extern inline" is ok would be very reasonable. Maybe you could even say that "extern inline" is honoured even when not optimizing. > I prefer to follow the standard where it says that inline is a hint, > and only a hint. You also seem to prefer breaking documented behaviour. You also seem to want to ignore the knowledgeable user that knows, for example, that yes, this is a frigging big inline, but it's only used in one place, and it's inline in order to make the code more readable, but I really want to have the compiler inline it for me to make the code faster. Why not just say that for "extern inline" there are NO artifical limits, because the damn documentation _tells_ you that "extern inline" is a gcc extension to the language that creates a macro-like function. Instead of breaking stuff that used to work. Linus