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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: What is wrong with OO ? Date: 1997/01/11 Message-ID: #1/1 X-Deja-AN: 209147372 references: <97011009463976@psavax.pwfl.com> organization: New York University newsgroups: comp.lang.ada Date: 1997-01-11T00:00:00+00:00 List-Id: Marin David Condic said " I am mildly disturbed by the notion that the compiler should perform inlining on its own with no input from the programmer - at least if the target is an embedded system. There are times when you want to force inlining for speed isues and there are reasons you may want to totally supress inlining for verification issues." Compilers are always free to generate any code that meets the semantic specifications of the language, and inlining (apart from the issue of creating body dependencies in the interunit case in Ada) is semantically neutral, so of course a compiler can perform inlining whenever it feels like it. Now, you may want for various special purposes, such as those you mention above and others, to have ways of limiting the basic semantic freedom of a compiler to generate any semantically correct code. Such compiler options are common, but have very little to do with source language syntax or semantics. Note that there *is* no way in the Ada *language* of forcing or preventing inlining. The use of pragma inline simply controls whether certain body dependencies are allowed to be created. An Ada compiler that delayed all code generation till link time, and at that time did all possible inlining across units, even in the absence of any pragma inline statements in the source, is a perfectly valid implementation of Ada.