1

Example:

// header.h
void foo ()  // function definition in the file
{
}

// file1.cpp
#include"header.h"
...

// file2.cpp
#include"header.h"
...

Above code will result in linker error. Suppose if the compiler makes inline foo() automatically then there will not be any linker error.

My question is on language perspective. Why the compiler doesn't make it inline automatically ? Will it make any difference ?

Question in other words: "What wrong can possibly happens if compiler assumes inline in front of every free function defined ?"

iammilind
  • 68,093
  • 33
  • 169
  • 336

5 Answers5

6

Headers are just treated as copy-paste of the header's text. The compiler has no idea your code is in a header rather than a source file so it has to treat both the same, allowing for the error. The language specifies this.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • How about compiler assuming keyword `inline` in front of every free function ? – iammilind Sep 28 '11 at 20:23
  • 5
    @iammilind Then you get inconsistent/silently wrong behaviour (instead of an error) as soon as you accidentially have two (different) functions of the same name. Just don't put definitions into headers (good practice for organization anyway) and add include guards (it's three lines per header). –  Sep 28 '11 at 20:26
1

Well, the answer is, basically, the C++ standard requires it to behave this way, so it does. This is part of the One Definition Rule.

Practically, the compiler must generate the linker-visible function in case you actually use it elsewhere. E.g., the following file3.cpp must work:

void foo();
void call_foo() {
    foo();
}

and in order for that to work, the generated code for foo() must be available to the linker. The compiler only looks at one translation unit (the .cpp file, plus everything included in it) at once, so it can't know that its actually generating it twice. So it does. Then the linker catches it.

derobert
  • 49,731
  • 15
  • 94
  • 124
1

That doesn't result in a linker error. It may result in a linker error but a compiler is not required to catch that error.

Cross-module consistency is entirely a responsibility of the programmer. The C++ compiler is not required to be able to see for example that you are using the same class name in two unrelated files with different class definitions. Whatever happens it's your fault.

In general many apparently strange weaknesses of the C++ compiling model are related to the fact that it must be possible to compile a C++ program by looking only at one module (compilation unit) at a time. Is is needed to ensure that compile time and space is not going to explode for large projects.

6502
  • 112,025
  • 15
  • 165
  • 265
0

It can inline it (but if it's not static it still has to have the function separately), but you are missing the point.

The compiler sees that you defined the function with the same signature twice. They could potentially differ. So at the linking phase it will generate an error to let you know that something bad is going on.

Put the declaration in the header void foo ();, and implement the function in one of the cpp files.

Karoly Horvath
  • 94,607
  • 11
  • 117
  • 176
0

Problem with automatically inlining at link time, given how C is defined, is if two different functions with the same name exist. The underlying binary interfaces don't maintain necessary meta-data to resolve such collisions. Throw in a third source file that uses (but does not define itself) a function with such a name, and it will have no idea which one is supposed to be used.

I suspect there may be some experimental C (or more likely C-like) compilers out there that do this, but they are pretty much guaranteed to break compatibility in some way.

Remy
  • 329
  • 1
  • 10