This code executes normally in VS2014, despite the fact that an inline member function is not defined in every TU in which it is odr-used.

Question

Consider this code:
header.h:
#include <iostream>
class A{
int i;
public:
A() : i(101) {}
void print();
void g(A&);
cpp1:
#include "header.h"
inline void A::print() { std::cout << i << '\n'; }
int main()
A a;
a.print();
g(a);
cpp2:
#include "header.h"
void g(A& a) { a.print(); }
Note that the member function A::print is defined outside its class with the specifier inline. The code executes normally in VS2014, despite the fact that the member function is odr-used in cpp2, but it is not defined in this file.
I found the following quotes from the C++11 Standard:
9.3/3:
An inline member function (whether static or non-static) may also be defined outside of its class definition provided either its declaration in the class definition or its definition outside of the class definition declares the function as inline.
3.2/3:
An inline function shall be defined in every translation unit in which it is odr-used.
7.1.2/4:
An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case.
The two last quotes above don't speak exactly about a member function but I believe they should be applied in this case too, as the inline specifier is a hint for the compiler to expand the function inline at the point of call. If we assume the compiler
does this inline expansion, how does it know the definition of the member function, while compiling the cpp2 file?  

Answer 1

On 12/31/2014 12:13 PM, Belloc wrote:
C++ is supported on many different systems, with tools provided by many different vendors. Microsoft's linker happens to be pretty smart about merging identical blocks of code. Other toolchains may use linkers that weren't designed with this in mind,
and that would choke on multiple definitions of the same symbol. The C++ standard is written so that it's actually implementable, on as many platforms as possible.
Frankly I don't understand your statement above. What would be the difficulty for any compiler*that is already compliant with 3.2/3 and 7.1.2/4*, to adapt its code, so that each call to an inline function in a TU, which doesn't carry the function
definition, is simply not inlined?
That's the easy part. The "there's identical function definition in every .obj file, and the linker is expected to merge them all together" is the hard part. Normally, if you define a regular (non-inline) function in more than one source
file, you get a linker error. Microsoft's linker has a special way to mark "defined more than once, just pick any copy" block of code (see __declspec(selectany) ). Other linkers may not.
Igor Tandetnik