What is linkage in c plus plus?

Answer 1

"An identifier declared in different scopes or in the same scope more than once can be made to refer to the same object or function by a process called linkage"

Types:- External, Internal and None linkage

Example:-

External Linkage= extern int a1;

Internal Linkage= static int a2;

None Linkage= int a3;

Answer 2

Linking in C++ (or in any language for that matter) is the process of combining the pieces of generated code from one or more compilations along with pieces of stored code from one or more libraries, and in joining inter-piece (i.e. inter-module)references to produce a fully executable load module.

Answer 3

A name that is declared outside of the translation unit that defines the name has external linkage. A name that can only be used by the translation unit that defines the name has internal linkage. A name that is not visible to the linker has no linkage.

// file1.cpp

int x = 1; // x has external linkage

const int y = 42; // y has internal linkage

int g() { int z=1; return z; } // z has no linkage.

The variable x has external linkage because it is declared at file scope in the global namespace. Thus another translation unit can gain access to it by declaring it with the extern keyword:

// file2.cpp

extern int x;

int f() { x = 42; }

Although permitted, global variables like x (of any type) are best avoided. Placing the variable in a namespace other than the global namespace can help but ultimately there's no real control over which code can physically alter a global variable's value (any programmer can gain access to your variable and data races can be particularly problematic). If you must use global variables, limit their scope as much as possible. One of the simplest ways to do so is to declare them static:

// file1.cpp

static int x = 1;

The static keyword is an unfortunate consequence of C++ inheriting from C, but it basically means internal linkage in this context. In other words, static variables declared at file scope are only accessible to that file and therefore have internal linkage.

Constants are less of a problem as they have internal linkage by default. However, being constants (rather than variables), it is often useful to give them external linkage so that other translation units can gain access to them. To do so, explicitly define the constant with external linkage:

// file1.cpp

extern const int y = 42;

// file2.cpp

extern const int y;

It is best to avoid polluting the global namespace unnecessarily with external linkage. A user-defined namespace is a better option:

// file1.cpp

namespace my_names

{

extern const int y = 42; // external linkage

};

// file2.cpp

extern const int my_names::y;

In order to ensure consistency with external linkage, place the declarations in one or more header files and include those headers wherever they are required.

The following demonstrates a working program using both internal and external linkage:

// file1.h

#include<iostream>

namespace my_names

{

extern const int y; // external linkage (defined in file1.cpp)

};

int g(); // external linkage (defined in file2.cpp)

// file1.cpp

#include "file1.h"

extern const int my_names::y = 42; // external linkage

static int x = 1; // internal linkage

int main()

{

using namespace my_names;

using namespace std;

cout << "x = " << x << endl;

cout << "y = " << y << endl;

cout << "g = " << g() << endl;

}

// file2.cpp

#include "file1.h"

int g()

{

using namespace my_names;

return y; // external linkage (defined in file1.cpp)

}

Note that it is vital that a definition for each declared name must appear once (and only once) in any one compilation, regardless of internal or external linkage. This is know as the one definition rule (ODR). Note also that it does not matter which translation unit contains the definition of an external linkage; even if the compiler cannot see the definition, the declaration alone is enough to appease the compiler. External linkage is resolved by the linker.

Templates are often problematic because the compiler does not generate any code for a template until it is actually used. This is because templates are incomplete types and it is their usage that ultimately generates the required code for a particular type. The type itself may use external linkage, but the template cannot -- it must be fully-defined even if the type is not. The simplest solution is to define the template within the same header that contains its declaration (keeping the interface and implementation details separate but still within the same file). In this way the compiler has all the information necessary to generate an instance of the template, even if the actual type used by the template employs external linkage. It is not an ideal solution in terms of hiding a template's implementation details from end-users, but that may be addressed in a future standard. But for now, it is enough to know that you cannot use external linkage to define a template.

One workaround to the problem is to declare the template in one header and then define it in another header which is included immediately after the declaration. While this helps to keep the interface separate from the implementation, it does not make use of external linkage to do so and does nothing to physically hide the implementation details from end-users.

Answer 4

Linking is the process that follows compilation. The compiler creates object files which are the machine code files produced by each translation unit in your program. These object files need to be linked together in order to produce the final executable.

Object files help speed up the compilation process because only those translation units that have changed since the last compilation need be recompiled.

Answer 5

The linker (or binder) takes object and library files and combines them into one load module. In the process, it resolves inter-file references, such as calls to an API in a library. These are the references that exist when you declare something extern, either explicitly with extern or implicitly by referencing a symbol that is not defined in the scope of the referencing file.