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.
> Same goes for using inline functions before declaring them - there's no > point in even asking the compiler to do global parsing (a compiler may > offer it if it wants to, but requireing it is fairly obnoxious). That type of reasoning is not very standards-minded, but more like special casing things that current compilers would generally do? And besides, note that other compile hints, such as the "register" attribute doesn't have to be adhered to, either. It is safest when programming languages specify the semantics of the program, and not bind some implementation meaning in... If for some reason the compiler cannot inline it, then I think it is reasonable to generate non-inlined code. > 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. And compilers are dumb, so what should the compiler do with a register attribute, when no registers are left? Abort the compile run or settle for the less perfect choice by allocating a stack frame slot? I understand what your point is, i.e., I don't think the compiler should CHOOSE to ignore the programer, but there can be a number of reasons why the compiler may have no other choice. I think that is what Joe was trying to tell you. (And the reasons behind the compiler not being to inline some functions may include deficiencies in the compiler, as well as cost/benefit tradeoffs relating to memory availability. I must say I hate the latter type of limitations and just wish all tools had a switch to use as much memory as deemed necessary...) m. -- Michael K. Gschwind IBM T.J. Watson Research Center phone (external): (914) 945-3162 PO Box 218 phone (internal): T/L 862-3162 Yorktown Heights, NY 10598 e-mail: mikeg@watson.ibm.com