From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1997/01/17 Message-ID: #1/1 X-Deja-AN: 210332658 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <32D53473.4DAA423A@eiffel.com> <01bbd235$b0f3fbe0$LocalHost@christophe-leph> content-type: text/plain; charset=ISO-8859-1 organization: Home's where my rucksack's mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-17T00:00:00+00:00 List-Id: >>> "gaijin" =3D=3D Vos nom et pr=E9nom writes: piercarl> It seems contrary to reasonabless: there are many contexts piercarl> where inlining is not necessary and others in which it is piercarl> important, *even for the same procedure*. Thus there is piercarl> (usually) a space/time tradeoff, but *at each call site*. It piercarl> sounds astonishing to me an argument that the compiler should piercarl> try to second guess or infer space/time tradeoffs (except piercarl> perhaps in the simplest cases), in addition to doing its job piercarl> of compiling valid translations of a source. gaijin> Here's my 2cts... If the function is very short, it's obvious gaijin> for the compiler to automatically inline it. When it's long, gaijin> it's also obvious not to make it inline. But where is the point gaijin> where the short function becomes a long function ? For all gaijin> these cases, it's the programmer's responsability to inline or gaijin> not regarding size vs speed. Those are good points, but not necessarily true. The situation is *really* subtler than most people think. Consider the two extremes: Should we always inline very short functions? Not necessarily, because this makes a number of activities, from profiling to debugging/backtracing rather harder, for it breaks simple correspondences between the structure of the source and that of the generated code. Also, it is not always worth doing it, and by default it should not be done unless there is a clear advantage; consider for example an inline functione like: vs(x) { return (x > 0) ? take_a_long_time : also_take_along_time)() ; } Should we always leave outofline very long functions? Not necessarily, because when they are inlined they might shrink dramatically. Consider: vl(x) { if (x < 0) return 0; else { ... /*lots of lines*/ }; } .... vl(-23); // this is worth inlining Again the choice depends often on the context of the call site.