\nMore than once, I’ve seen somebody confused by how inline functions work.\n<\/P>\n
\n\nI have implemented a few inline functions in one of my cpp files,\nand I want to use it from other cpp files,\nso I declare them as
extern<\/CODE>.\nBut sometimes I will get linker error 2019 (unresolved external)\nfor the inline functions.\n<\/P>\n\n\/\/ a.cpp\ninline bool foo() { return false; }<\/p>\n\/\/ b.cpp\nextern bool foo();<\/p>\n
bool bar() { return foo(); }\n<\/PRE>\n<\/BLOCKQUOTE>\n
\nYup, that’s right.\nThe C++ language says in section 3.2(3) [C++03, C++11],\nand repeats in section 7.1.2(4) [C++03, C++11],\n<\/P>\n
\nAn inline function shall be defined\nin every translation unit in which it is used.\n<\/BLOCKQUOTE>\n\n(A translation unit<\/I> is the technical term for what\nwe intuitively can think of as a single cpp file and all the\nfiles that it
#include<\/CODE>s.)\n<\/P>\n\nBy putting the definition of
foo<\/CODE> in a cpp file,\nyou make its definition visible only to that cpp file and\nno other cpp file.\nWhen you compileb.cpp<\/CODE>,\nsees that you declared it as a normal external function,\nso it generates a call to it like a normal external function.\nOn the other hand, when you compilea.cpp<\/CODE>,\nthe compiler sees thatfoo<\/CODE> is an inline function,\nso it says,\n“I don’t need to generate any code yet.\nInline functions generate code at the point they are invoked,\nnot at the point they are defined.”\n<\/P>\n\nResult:\n
b.cpp<\/CODE> asks for a definition offoo<\/CODE>,\nbut nobody provides it,\nbecause the two declarations were inconsistent.\nThis is a violation of\n7.1.2(4) [C++03, C++11]\nwhich says\n“If a function with external linkage is\ndeclared inline in one translation unit,\nit shall be declared inline in all translation units in which it appears;\nno diagnostic is required.”\nThe magic phrase no diagnostic is required<\/I> means that the compiler\nis not even required to report the error.\n(You’re lucky that it did!)\n<\/P>\n\nThis rule makes sense when you think about the classical model of\ncompiling:\nThe compiler logically\ntakes the source code and sends it through the\npreprocessor.\nThe result (the translation unit<\/I>)\nthen goes into the compiler proper,\nwhich learns about structures and classes and functions,\nand it generates code based on what it sees in that\ntranslation unit.\nThe compiler does not have access to other translation units,\nso when compiling
a.cpp<\/CODE> it can’t peek into\nb.cpp<\/CODE> and say,\n“Hm, it looks like somebody is going to be callingfoo<\/CODE>\nas a non-inline function,\nso let me also generate a non-inline version of it.”\nAnd similarly,\nwhen the compiler is generating code for the\nbar<\/CODE> function,\nit doesn’t peek intoa.cpp<\/CODE> and say,\n“Hm, it looks likefoo<\/CODE> is actually an inline\nfunction.\nLet me go steal its definition from that other file.”\n<\/P>\n