inline functions...

[John Ratliff]

I was reading the C++ FAQ Lite about inline functions, and it says the
following
(http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.7)

" It's usually imperative that the function's definition (the part between
the {...}) be placed in a header file. If you put the inline function's
definition into a .cpp file, and if it is called from some other .cpp file,
you'll get an "unresolved external" error from the linker. "

Why will the linker not be able to resolve this?

Thanks,

--John Ratliff

 

[Steven T. Hatton]

I was reading the C++ FAQ Lite about inline functions, and it says the
following
(http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.7)

" It's usually imperative that the function's definition (the part between
the {...}) be placed in a header file. If you put the inline function's
definition into a .cpp file, and if it is called from some other .cpp
file, you'll get an "unresolved external" error from the linker. "

Why will the linker not be able to resolve this?

Thanks,

--John Ratliff

I'm trying to become an expert in linking in my spare time. It really is
a broad subject.

My guess as to why you "need" to put the inline function sin the "header"
file is because they must be visible when the compiler uses the class
definition.

Note that the definition of a class begins with the class heading, and ends
with the };. Even if the member functions are not defined at the time the
compiler finishes with the class body, the class is defined.

inline functions get placed directly into the object code for the routine
that invokes them. This is different than what happens with non-inline
functions. With them, all you need as a signature. The linker can take
care of finding them when they are needed.

 

[Girish Shetty]

Lets take some example:
You have some header in which u have declared that function as inline

//SomeHeader.h
inline void Somefunction();

//SomeCpp.cpp
#include "SomeHeader.h"

inline void Somefunction()
{
// Implementaion..
}

Suppose u are using this function SomeFunction..
//SomeOtherCpp.cpp

void Function()
{
....
Somefunction();
...
}

Now, it has to get the defination of SomeFunction during compile time for
the inline replacement.
But with this compiler unit ( not linking unit) which includes SomeHeader.h
and someOtherCpp.cpp file, there it wont get the implementation of inline
function !!
So, is the problem.

So, usually we implement them in .h files only.
Or, if you take Symbian, it prefers .inl (inline) file which defines inline
function implementation and is included at the end of the corresponding .h
file

Regards
Girish

 

[John Ratliff]

Thanks. I understand now.

--John Ratliff

 

[Alf P. Steinbach]

* John Ratliff:

I was reading the C++ FAQ Lite about inline functions, and it says the
following
(http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.7)

" It's usually imperative that the function's definition (the part between
the {...}) be placed in a header file. If you put the inline function's
definition into a .cpp file, and if it is called from some other .cpp file,
you'll get an "unresolved external" error from the linker. "

Why will the linker not be able to resolve this?

A particular C++ implementation may do anything. The FAQ just mentions the
most common in-practice case (there should perhaps be some lawyereese
qualification and disclaimer, but then it would soon get out of hand and
become unreadable, sort of like the standard). Formally §3.2/3 requires
that an inline function is defined in every translation unit it's used in.

In fact, with MSVC 7.1 you can do e.g.

inline void f();
int main(){ f(); }

in one .cpp file, and

#include <iostream>
#include <ostream>
void f() { std::cout << "huh" << std::endl; }

in another, and the linker will be happy.

This program is not formally valid because §7.1.2/4 says that if a function
is declared inline in one translation unit, it shall be declared inline in
all translation unit it appears in, which is why the FAQ recommends doing it
in a header file. However, as the standard says, "no diagnostic is
required". And that's what MSVC 7.1 does, no diagnostic.

 

[Alf P. Steinbach]

* Steven T. Hatton:

inline functions get placed directly into the object code for the routine
that invokes them.

Correction: may.

This is different than what happens with non-inline functions.

Correction: this is the same as...


Cheers,

- Alf

 

[Zorro]

I'm trying to become an expert in linking in my spare time. It really is

a broad subject.

My guess as to why you "need" to put the inline function sin the "header"
file is because they must be visible when the compiler uses the class
definition.

Note that the definition of a class begins with the class heading, and ends
with the };. Even if the member functions are not defined at the time the
compiler finishes with the class body, the class is defined.

inline functions get placed directly into the object code for the routine
that invokes them. This is different than what happens with non-inline
functions. With them, all you need as a signature. The linker can take
care of finding them when they are needed.

I thought a little history might be useful. You are right as to what
inline implies, but slightly off from what it has become.
The experimental compiler (early days) would generate error for many
cases of inline. For instance, if you included a for-loop it would say,
"Sorry, for-loop not implemented for inline, yet", or something
like that.
This became annoying, and would not be easy to maintain for commercial
compilers. For instance, to remove the error (or warning) when it
became possible to do so required maintenance.
It was decided to treat inline as a request to the compiler. Thus,
compiler will do inline if it can, otherwise it will pass it on to
linker for (external) linkage.
Recently (well, a few years ago) there were some complications in
separate compilations (projects involving multiple source files)
involving C and CPP source files, with regard to inline. It was decided
to allow external linkage for inline functions, anyway. That should
explain the behavior of VC++.
Again, your statement correctly explains the linkage error. However,
there were deviations from the original intent. In the case posted
here, the particular compiler is not creating external linkage, so the
linker cannot resolve the symbol (the call). The designers are taking
your view.

Hope this helps.

Regards,
(e-mail address removed)
http://www.zhmicro.com
http://distributed-software.blogspot.com