Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: Pre-proposal: ~const [Rev 1.6] Message-ID: <60331@microsoft.UUCP> Date: 7 Jan 91 23:30:55 GMT References: <60083@microsoft.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Distribution: comp Organization: Microsoft Corp., Redmond WA Lines: 40 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: |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. I disagree. I follow the suggested practice of using inline functions wherever possible where macros might have been used in the past. Inlines are preferable because they are more type safe, and provide better compile time error messages. If these functions are not inlined, my code will double or triple in size. Also, I use inline functions where the intent is that the compiler "customize" code for a particular application. In order for "customization" to happen, the code must be inlined, or again several times larger, slower code will occur. In my usage, fairly large inline functions are designed with the intent to generate a small amount of customized inline code, whereas a outlined, uncustomizable version of the code would be both much larger and much slower. However, these inlines can be a bear to debug. And I can't afford to make all my inline functions outline for debugging, since several times larger slower "uncustomized" code will result. Therefor, what I need is the ability to simply and easily specify a certain small set of functions to not be inlined. ~inline would be one such an approach. Another, less elegant approach would be to use some kind of #pragma not inline, or the such.