Created on 2001-10-14.00:00:00 last changed 196 months ago
[Voted into WP at October 2005 meeting.]
Proposed resolution (October, 2004):
Add the indicated words to 9.2.3 [dcl.fct.spec] paragraph 4:
An inline function shall be defined in every translation unit in which it is used and shall have exactly the same definition in every case (6.3 [basic.def.odr]). [Note: a call to the inline function may be encountered before its definition appears in the translation unit. —end note] If the definition of a function appears in a translation unit before its first declaration as inline, the program is ill-formed. If a function with external linkage is declared inline in one translation unit...
Steve Clamage: Consider this sequence of declarations:
void foo() { ... } inline void foo();The non-inline definition of foo precedes the inline declaration. It seems to me this code should be ill-formed, but I could not find anything in the standard to cover the situation.
Bjarne Stroustrup: Neither could I, so I looked in the ARM, which addressed this case (apparently for member function only) in some detail in 7.1.2 (pp103-104).
The ARM allows declaring a function inline after its initial declaration, as long as it has not been called.
Steve Clamage: If the above code is valid, how about this:
void foo() { ... } // define foo void bar() { foo(); } // use foo inline void foo(); // declare foo inline
Bjarne Stroustrup: ... and [the ARM] disallows declaring a function inline after it has been called.
This may still be a good resolution.
Steve Clamage: But the situation in the ARM is the reverse: Declare a function inline, and define it later (with no intervening call). That's a long-standing rule in C++, and allows you to write member function definitions outside the class.
In my example, the compiler could reasonably process the entire function as out-of-line, and not discover the inline declaration until it was too late to save the information necessary for inline generation. The equivalent of another compiler pass would be needed to handle this situation.
Bjarne Stroustrup: I see, and I think your argument it conclusive.
Steve Clamage: I'd like to open a core issue on this point, and I recommend wording along the lines of: "A function defined without an inline specifier shall not be followed by a declaration having an inline specifier."
I'd still like to allow the common idiom
class T { int f(); }; inline int T::f() { ... }
Martin Sebor: Since the inline keyword is just a hint to the compiler, I don't see any harm in allowing the construct. Your hypothetical compiler can simply ignore the inline on the second declaration. On the other hand, I feel that adding another special rule will unnecessarily complicate the language.
Steve Clamage: The inline specifier is more than a hint. You can have multiple definitions of inline functions, but only one definition of a function not declared inline. In particular, suppose the above example were in a header file, and included multiple times in a program.
History | |||
---|---|---|---|
Date | User | Action | Args |
2008-10-05 00:00:00 | admin | set | status: wp -> cd1 |
2006-04-22 00:00:00 | admin | set | status: dr -> wp |
2005-10-22 00:00:00 | admin | set | messages: + msg1278 |
2005-10-22 00:00:00 | admin | set | status: ready -> dr |
2005-05-01 00:00:00 | admin | set | status: review -> ready |
2004-11-07 00:00:00 | admin | set | messages: + msg1057 |
2004-11-07 00:00:00 | admin | set | status: open -> review |
2001-10-14 00:00:00 | admin | create |