What is the point of internal communication in C ++

Question

I understand that there are three possible binding values ​​for a variable in C ++ - lack of binding, internal communication, and external communication.

Thus, an external link means that the identifier of a variable is available in several files, and an internal link means that it is available in one file. But what is the essence of internal communication? Why not just have two possible connections for an identifier - no connection and no external connection? It seems to me that the global (or file) area and internal communication serve the same purpose.

Is there any precedent when intercom is really useful that is not covered by a global area?

In the example below, I have two pieces of code - the first is connected to a static int i11 (which has an internal connection), and the second is not. Both pretty much do the same thing, since main already has access to the i11 variable due to its file area. So why is there a separate connection called an internal connection.

static int i11 = 10; int main() { extern int i11; cout << ::i11; return 0; } 

gives the same result as

 static int i11 = 10; int main() { cout << ::i11; return 0; } 

EDIT:. To add clarity, as defined by HolyBlackCat below, internal communication does mean that you can forward a variable in the same translation unit. But why do you even need to do this for a variable that is already available globally in the file. Is there any use case for this feature?

Answer 1

Examples of each of them:

External communication:

 foo.h extern int foo; // Declaration foo.cpp extern int foo = 42; // Definition bar.cpp #include "foo.h" int bar() { return foo; } // Use 

Intercom:

 foo.cpp static int foo = 42; // No relation to foo in bar.cpp bar.cpp static int foo = -43; // No relation to foo in foo.cpp 

No links:

 foo.cpp int foo1() { static int foo = 42; foo++; return foo; } int foo2() { static int foo = -43; foo++; return foo; } 

Of course, you will agree that the variables foo in the functions foo1 and foo2 must have memory. This means that they probably should have names because of how assemblers and linkers work. These names cannot conflict and should not be accessible by any other code. The way the C ++ standard encodes is "lack of communication." There are a few more cases where it is used, but for things where it is a little less obvious what the store is used for. (For example, for class you can imagine that vtable has storage, but for typedef , we are mostly talking about the limitations of the language specification in the area of ​​name access.)

C ++ indicates some communication model with the lowest common denominator, which can be compared with richer models of real linkers on real platforms. In practice, this is very imperfect, and many real systems end up using attributes, pragmas or compiler flags to gain more control over the type of connection. To do this and still provide a reasonably useful language, you get the ability to manipulate names and other compiler methods. If C ++ ever tried to provide a greater degree of compiled code interaction, for example, with Java or .NET virtual machines, it is very likely that the language will get more precise and more thoughtful control over the connection.

EDIT: To answer the question more clearly ... The standard should determine how this works both for accessing identifiers in the source language and for linking compiled code. The definition must be strong enough so that correctly written code never leads to errors for things that were undefined or repeatedly defined. Of course, there are more effective ways to do this than using C ++, but it is a largely developed language, and the substrate to which it is compiled affects the specification to some extent. There are actually three different types of relationships:

• External communication: the entire program agrees with this name and can be accessed wherever there is an announcement.
• Internal binding: one file agrees with this name, and it can be accessed in any scope of the ad.
• No binding: the name refers to only one scope and is available only in this scope.

In an assembly, they tend to appear in the global declaration, local file declaration, and local file declaration with a synthesized unique name.

This is also true for cases when the same name is declared with different relationships in different parts of the program and when determining that extern int foo refers to a given location.

Answer 2

External communication is related to the fact that the files are compiled independently of each other (the files # included.h, .c and .cpp are not compiled independently of each other). An external variable is different in that it can be used between compiled files.