Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Inline functions and locals Date: Mon, 17 Jan 2022 15:34:46 -0800 Organization: A noiseless patient Spider Lines: 27 Message-ID: <865yqirl61.fsf@linuxsc.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d40b94b342f96ad99b493372f9984bf0"; logging-data="13427"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//MPrncwMT2MiDTi1ox5SMSjn2JemoA4Y=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:McSi/kkigGAaWG5LEjnzC0VHT3E= sha1:ZCRldkbgQg5dXV3SbnOMI5JOYeM= Xref: csiph.com comp.lang.c++:82809 James Kuyper writes: > On 1/17/22 4:50 AM, Juha Nieminen wrote: > ... > >> Since as far as I remember you cannot have 'static' variables inside >> an 'inline' function (unlike in C++), > > That only applies to inline functions with external linkage, and only > for modifiable objects. The same is true of objects with thread storage > duration. Such functions are also prohibited from containing a reference > to an identifier with internal linkage. (C standard 6.7.4p3) > > A key difference between C and C++ that is relevant to this thread is > that, in C++, 'inline' is an ignorable hint that inline substitution > should be performed. In C, it's an ignorable hint that "that calls to > the function be as fast as possible.", with the method where by that > might be achieved being unspecified. Note the sentence in the semantics portion of 6.7.4 of the C standard that says The extent to which such suggestions are effective is implementation-defined. So I think "implementation-defined" is more accurate than "unspecified".