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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: What is wrong with OO ? Date: 1997/01/09 Message-ID: #1/1 X-Deja-AN: 208820091 references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <32D53473.4DAA423A@eiffel.com> organization: New York University newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-09T00:00:00+00:00 List-Id: Bertrand says "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 misunderstands the function of pragma Inline in Ada. This is NOT a directive that the compiler should inline the function, not at all, it is simply a permission to establish a compilation dependency on the body, an obvious prerequisite for permitting the inlining. If you want to let the compiler do unlimited automatic inlining, then you simply label every visible function as being pragma Inlined. Then the compiler has complete freedom to inline anything. Of course it will still only inline things if it makes sense to do so, which is something that requires a lot of low level input (just measuring the number of bytes of code is far too crude). If it was consdered useful to allow unlimited inlining in Ada, it would be trivial, and very much within the spirit of the language to add a configuration pragma Inline_All (implementations of Ada are allowed to add such configuration pragmas, or it could simply be a compiler switch). To implement such a switch would be about thirty minutes work in GNAT, but I doubt it would be found to be of much use in practice, certainly no one has indicated an interest in such a switch. On the contrary, in large programs, people are VERY concerned about compilation dependencies. If any change to any unit requires recompiling ten million lines of code, then even with a fast compiler, the impact on development productivity is worrisome.