Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!princeton!siemens!gypsy!glu From: glu@gypsy.UUCP Newsgroups: comp.lang.modula2 Subject: Re: Re: Syntax to include procedures inl Message-ID: <5300001@gypsy.UUCP> Date: Thu, 11-Dec-86 13:02:00 EST Article-I.D.: gypsy.5300001 Posted: Thu Dec 11 13:02:00 1986 Date-Received: Mon, 15-Dec-86 03:07:34 EST References: <1654@k.UUCP> Lines: 26 Nf-ID: #R:k:-165400:gypsy:5300001:000:1345 Nf-From: gypsy!glu Dec 11 13:02:00 1986 Inline expansion imposes an additional *compile* dependency from one body (or implementation module) to another body. Therefore the user *has* to know whether inline expansion (across different modules) got done or not. Consider a case where X.def imports a procedure specified in Y.def. A legal compilation order is: Y.def, X.def, Y.mod, X.mod. If the compiler automatically does inline expansion on the imported procedure in X.mod without telling you, then you are in trouble. Why? Change the inlined procedure in Y.mod and recompile it. X.mod will still have the old version inlined - you have to recompile X.mod to get the right version! Whereas if inline expansion would not have been done then this wouldn't hurt - the dependency from X.mod to Y.mod then is just a *link* dependency. The PRAGMA INLINE as defined in Ada gives the user the power to direct inline expansion explicitly. The compiler would only do the expansion, if there is a valid body for a used spec in the library. Otherwise it would issue a warning. However, the absence of such a pragma does not prevent a compiler's optimizer from still doing local inline expansion within one compilation unit. So, if you really want to solve this problem in a totally transparent fashion, do it on binary after the program is linked. Raimund Gluecker princeton!siemens!gypsy!glu