Why is this inline class member function in C++ giving me an unresolved external reference error?

Question

I've been having some problems with declaring functions inline causing unresolved external reference linker errors. I must be misunderstanding something quirky about C++. I'm trying to reduce the compile time of my C++ SDK using a 3-file translation unit where there is one "codeless header" that has only declarations and no implementations, another "code header" that contains all of the templates with implementations, and a unique .cpp filename to minimize hashtable collisions. I'm trying to make either a statically compiled library, DLL, or compile directly into an executable. I want my functions to be inlined, but the problem is that this super basic code will not compile:

// in pch.h
#include <iostream>
#ifdef ASSEMBLE_DYNAMIC_LIB
#ifdef LIB_EXPORT
#define LIB_MEMBER __declspec(dllexport)
#else
#define LIB_MEMBER __declspec(dllimport)
#endif
#else
#define LIB_MEMBER
#endif

// in foo.h
#pragma once
#include "pch.h"
struct LIB_MEMBER Foo {
   Foo ();
   inline int Bar (); //< inline causes Unresolved external reference error???
};

// in foo.cpp
#include "foo.h"
Foo::Foo () {}
int Foo::Bar()

// main.cpp
#include "foo.h"

int main(int argv, char** args) {
  Foo foo;
  std::cout << "Hello StackOverflow. foo is " << foo.Bar();
  while (1)
    ;
}

The code results in this linker error:

Severity Code Description Project File Line Suppression State Error LNK2019 unresolved external symbol "public: int __cdecl Foo::Bar(void)" (?Bar@Foo@@QEAAHXZ) referenced in function main experiments C:\workspace\kabuki_toolkit\projects\experiments\main.obj 1

All of the code I've found on StackOverflow won't compile with the same error. For example:

// in foo.cpp
#include "foo.h"
Foo::Foo () {}
inline int Foo::Bar() {} //< Again, Unresolved external reference error :-(

The Visual-C++ documetnation has some stuff about how to inline a DLL class member, but they have no code examples.

Answer 1

In C++ inline functions must have their body present in every translation unit from which they are called, otherwise the program is ill-formed. (Ref: C++17 [basic.def.odr]/4)

Marking the class as dllexport or dllimport does not escape that requirement.

NB. The semantics of inline functions in exported classes are described on this MSDN page ; it's exported the same way as a non-inline function; and the importing compiler can choose whether to use the inline definition or the imported definition.

To fix this you could declare Bar as non-inline; or provide the body in the header, e.g.

struct LIB_MEMBER Foo {
    Foo ();
    void Bar () { } 
};

or, equivalently,

struct LIB_MEMBER Foo {
    Foo ();
    inline void Bar () { } 
};

inline void Foo::Bar() {}

As mentioned by the MSDN page, having an exported class with an inline function means that you can't safely change the function in a later release of the DLL without recompiling the client.

Answer 2

You've set ASSEMBLE_DYNAMIC_LIB to NO_0 in the header, which means all of the export flags are ignored. Your pre-processor usage is also wrong: You probably don't want to be using #ifdef, and should be using #if when posing a question...

#if ASSEMBLE_DYNAMIC_LIB == YES_0

If you intend for void Foo::Bar() {} to be inline, then move it to the header file. If it's in the cpp, you'll get an unresolved external error (potentially). It is however worth noting that MSVC will ignore inline in this context, given that you have asked to export the entire class (export overrules inline).

It is possible to export individual member functions as well, if you want to mix & match inline/exported.

class Foo {
public:
   LIB_MEMBER Foo ();
   OBJ_INLINE void Bar () 
     {}
};

Answer 3

Edit: I believe this answer is wrong. Preserved for the comments below.

It is recommended to read the entire documentation page before jumping to coding.

These rules apply to inline functions whose definitions appear within a class definition.

Your function definition does not appear within a class definition, only the declaration does.

Answer 4

foo.cpp won't compile because of the C++ standard (C++14 in this case) Section 9.3 states:

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. [ Note: Member functions of a class in namespace scope have external linkage. Member functions of a local class (9.8) have no linkage. See 3.5. —end note ]

4. There shall be at most one definition of a non-inline member function in a program; no diagnostic is required. There may be more than one inline member function definition in a program. See 3.2 and 7.1.2.

Also Section 3.4 also states:

An inline function shall be defined in every translation unit in which it is odr-used. Exactly one definition of a class is required in a translation unit if the class is used in a way that requires the class type to be complete.

The keyword to understand here is external linkage; If there is more than one definition of the symbol at link time then it can't be resolved because of the one definition rule1; all C++ class members defined in namespace scope have external linkage and there are multiple definitions of an inline symbol, one for each translation unit, so the external symbol can't be resolved; hence the compile error Unresolved External Symbol. When we put the definition of the declaration outside of the class and mark it inline, it's no different than putting the inline code in the header. So if we move the code from foo.cpp into main.cpp, it works because there is only one TU now and no violates of the one definition rule:

#include "foo.h"

Foo::Foo() {}

inline int
Foo::Bar() {  //< No undefined external refrence error.
  return 1;
}

int main(int argv, char** args) {
  Foo foo;
  std::cout << "Hello StackOverflow. foo is " << foo.Bar();
  while (1)
    ;
}

The error in logic of using inline in the declarations for the statically linked library is that we assume that the compiler will not inline the functions automatically using the optimizer. Compilers perform Link-Time Code Generation, or Whole Program Optimisation, where the linker will delay generating the code until link-time and will optimize the intermediate code without the use of a single inline tag2. The problem with using a 3-file translation unit with a DLL is that you're linking at runtime and the intermediate code got deleted so you can't use the Link-time Code Generation to inline the function, so you'll have to put inline functions in the "code header" with the templates.

Updated 9/14/2019 Answer

I have found a significantly more eloquent solution, and you can see an example in the Script2 SDK. The solution is that you only really want one translation unit. I just got 900KB of Script2 code to compile in about 4 seconds total, with 3 seconds spent on pch.cc. The trick is to rename your .cpp files to .inl files, which are inline header files, and include then all in another inline header, Script2 using the module_assembly.inl file. This will prevent you from having to pre-compile a statically linked library and lose the intermediate object code you need for the compiler to auto-inline your functions during the Whole program optimization phase. The new naming convention is that the "codeless header" is a .h file, the "code header" is a .hpp file, and the inline cpp file is .cc.inl file.