Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.std.c++ Subject: Re: Pre-proposal: ~const [Rev 1.6] Message-ID: Date: 3 Jan 91 14:53:02 GMT References: <60083@microsoft.UUCP> Sender: aro@aber-cs.UUCP Distribution: comp Organization: Coleg Prifysgol Cymru Lines: 25 Nntp-Posting-Host: teachk In-reply-to: jimad@microsoft.UUCP's message of 27 Dec 90 19:56:22 GMT On 27 Dec 90 19:56:22 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said: jimad> A complete list of keywords that I think could be possible candidates for jimad> negation is: jimad> [ ... ] jimad> ~inline do make this method outline -- IE a real function call. jimad> [ ... ] Let me home in on this. One problem of the current definition of 'inline' is that it specifies that every time the given function is called, it should be inlined. In other words, 'inline' currently means 'can inline, *must* inline'. The problem I see with this is that, for one of the two common reasons one wants to inline, in many cases expanding inline a function is irrelevant -- it is only productive in a few places, e.g. in inner loops, or where substantial opportunities for code merging exist. Inlining a function everywhere, unless it is very small, is just going to increase size with little benefit in speed. What is probably needed (not for C++ though) is a distinction between 'inlinable' and 'inline', where the first is used -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk