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.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)




  In message <Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com>yo
u write:
  > I'm also sorry that almost nobody saw the point of having a macro-like
  > inline. I don't like duplicating code like in libc (where code duplication
  > makes sense - having a "official compiled sequence" to link against, with
  > a separate version for inlining for optimization). As it is, I guess
  > "extern inline" is just useless for what I wanted to do, and nobody seems
  > to have a good alternative that doesn't result in more flamage, so while
  > I'm disappointed I'll just shut up and lick my wounds. 
Yea, the way this is handled (code duplication) is suboptimal, but it has been
the way the docs have suggested handling extern inline functions since at
least 1991.

  This combination of inline and extern has almost the effect of a macro.  The
  way to use it is to put a function definition in a header file with these
  keywords, and put another copy of the definition (lacking inline and extern)
  in a library file.  The definition in th header file will cause MOST calls
  to the function to be inlined.  If any uses of the function remain, then
  will refer to the single copy in the library.

Emphasis on MOST added by me.


jeff