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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Ken Garlington Subject: Re: What is wrong with OO ? Date: 1997/01/09 Message-ID: <32D573DE.6D23@lmtas.lmco.com>#1/1 X-Deja-AN: 208881772 references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <32D53473.4DAA423A@eiffel.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.01 (Win95; U) Date: 1997-01-09T00:00:00+00:00 List-Id: Bertrand Meyer wrote: > > ISE Eiffel does give the user a degree of parameterization: > a compilation option specifies the size threshold beyond which > a routine will not be inlined. This is measured in internal units > (number of bytecode words), but easy to relate to number of > instructions. This option provides a way to control space-time > tradeoffs. In practice, however, most users are happy with the > default, which inlines small, frequently called routines. This is the way the Ada compilers we use work as well. Here is an excerpt from one of the compiler manuals: Optimize=, where is: minimum - pragma Inlines are not obeyed. low - pragma Inlines are not obeyed. standard - some inline expansion time - aggressive inline expansion space - inline expansion only if smaller code results This is, of course, compiler specific (outside the language standard). I assume this is the case for Eiffel as well, since you called out a specific compiler implementation? > This automatic optimization is crucial because the object-oriented > style of development, with its emphasis on abstraction, naturally > tends to yield many small routines. With ISE Eiffel, you can write the > software as it should be, not asking yourself all the time "should > I violate abstraction here and avoid writing a small routine because > of the effect on performance?". You just leave this kind of concern > to the compiler. ("Inline" pragmas would be almost worse here, because > you would have to perform yourself the analysis of what is inlinable > and what is not. The incrementality problem is particularly nasty: > change a single line somewhere in a large system, and a routine that was > inlinable, > far away in the software text, now becomes non-inlinable! This > kind of systematic, exhaustive work, error-prone when done > by humans, is what computers are for.) This is the way we approach our Ada software, as well. We generally use pragma Inline for extreme cases, where we know that our choice is smarter than the compiler's... -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com