gary@dgcad.SV.DG.COM (Gary Bridgewater) (04/07/90)
In article <117671@ti-csl.csc.ti.com> NEATH@cgi.com writes: > >In article <117072@ti-csl.csc.ti.com> NEATH@cgi.com (me!) wrote about the >inlining policy of cfront 2.0 and the complextiy variable `imeasure'. When this >reaches 13, cfront decides not to inline >As such, that dosn't seem unreasonable: if you have 13 assignment statements in >a function, you probably shouldn't be inlining it all over the place. ^ why? >There are, however, other circumstances where the apparently somewhat arbitray >complexity measure of 13 is an annoyance. like, whenever it is invoked... >... To remedy this problem, it appears we must select from >one of the following unattractive options: >... > o Modify the cfront source code to allow a larger complexity measure so > that this particular case actually stays inline. There you go. >It would seem that the inline recommendation to the compiler is a far trickier >subject to deal with than some static complexity measure. Here's a bizarre thought - just let the programmer decide. If, for example, the programmer inserts an "inline" keyword then inline. If not, then don't.* There is always the outside chance the programmer did/did not use the "inline" keyword for a reason. Call it a 50-50 chance, if you will, so, on average, it can't hurt. After all, who suffers from the wrong decision? If the general c++ community doesn't understand inlining then let them post questions and get answers. It isn't the compiler that breaks the program. >Why, for example, are `for' loops disallowed in inline functions, but `while' >loops tolerated? Why is anything disallowed? If it is currently beyond the coders to inline certain things then document that as a deficiency, not a feature. ... * Actually, the complier (C++ or the underlying cc) may be able to decide TO inline in some cases - I don't want to restrict that feature other than wrt debugging when the rule should be "what you code is what you get". -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary The impossible we understand right away - the obvious takes a little longer.