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: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: Bart Samwel Subject: Re: What is wrong with OO ? Date: 1997/01/10 Message-ID: <32D64931.167E@wi.leidenuniv.nl>#1/1 X-Deja-AN: 208931168 references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> content-type: text/plain; charset=us-ascii organization: Dept. of Math. and Comp.Sci.; Leiden Univ.; Leiden; the Netherlands 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 2.0 (X11; I; IRIX 5.3 IP22) Date: 1997-01-10T00:00:00+00:00 List-Id: Robert wrote: > "You shouldn't bother programmers with inlining. Inlining can be done > automatically by the compiler." > > I don't see this is possible across modules without violating the > integrity of separation of specs and implementations. In C++, it's not possible, that's true. This is because C++ uses a modular model that completely separates different parts of the system. When compiling one module, the compiler doesn't know anything about the other modules other than that they are there and their specifications. This makes automatic inlining very hard, because the implementation is just _not available_ to the compiler! The problem here is that C++ honours the principle of modularity, which is a Good Thing, but fails to recognize the fact that many modules form a System as a whole. This results in C++ not doing any global analysis of programs, so that it cannot automatically detect functions which need dynamic binding ("virtual"), it cannot choose to inline functions which were not designated by their writer to be inlined, and it cannot perform optimizations that cross module boundaries (these optimizations would be valid only within the system they were performed on, so that when you use some of the modules in another system, other optimizations might be chosen). In languages like Eiffel, which provide for global analysis of the system, automatic inlining is possible. It is even possible to inline one call to a function (for instance, within a loop), and not to inline another call in the same function, only a few lines later. As for separation of specs and implementations: C++ violates this too, by forcing inline functions to be defined in the class INTERFACE specification. With global analysis, you can still keep this separate, and even better, because you don't have to put the inline function in the interface: the global analysis has access to the implementation anyway, so you don't need that anymore. The point I have here is that the fact that the implementation is visible to the compiler does not directly imply it should visible to the programmer. Bart