link,ge related to long distant friendship

[puzzlecracker]

I have encountered certain confusion while scrutinizing the long
distance friendship engendering violation of encapsulation.

If object (be it a class, variable, function, etc) has an internal
linkage let's say defined in the .c file or with a word static (by the
way definition of anything in .c imply internal linkage?). And the same
name object is defined with external linkage; let's say in the .h file.
The question is whether there is a conflict during linking/compilation
phase.

Does internal linkage override the external one?

thanks...

 

[Sharad Kala]

I have encountered certain confusion while scrutinizing the long
distance friendship engendering violation of encapsulation.

If object (be it a class, variable, function, etc) has an internal
linkage let's say defined in the .c file or with a word static (by the
way definition of anything in .c imply internal linkage?). And the same
name object is defined with external linkage; let's say in the .h file.
The question is whether there is a conflict during linking/compilation
phase.

Read 7.1.1/7 - "The linkages implied by successive declarations for a given
entity shall agree. That is, within a given scope, each declaration
declaring the same object name or the same overloading of a function name
shall imply the same linkage. Each function in a given set of overloaded
functions can have a different linkage, however."

Does internal linkage override the external one?

Yes. The examples given are -

static int a; // a has internal linkage
int a; // error: two definitions

static int b; // b has internal linkage
extern int b; // b still has internal linkage

int c; // c has external linkage
static int c; // error: inconsistent linkage

extern int d; // d has external linkage
static int d; // error: inconsistent linkage

Sharad

 

[msalters]

If object (be it a class, variable, function, etc) has an internal
linkage let's say defined in the .c file or with a word static (by the
way definition of anything in .c imply internal linkage?). And the same
name object is defined with external linkage; let's say in the .h file.
The question is whether there is a conflict during linking/compilation
phase.

I think you're confusing linkage with visibility. After the
preprocessor
is done with the #include's, the compiler can't see where what
originated.
It doesn't care. On the other hand, the preprocessor doesn't deal with
linkage.

To get internal linkage, you typically write static int x; at file
scope.
Now, you typically want it to be internal to one .cpp file, so you put
it
in a .cpp file. It is legal to put it in a .h file. In that case, every
..cpp file that includes the .h (in)directly gets a separate x.

With external linkage, every declaration refers to the same object.
That
in turn means you should have one definition, but you can have a lot of
declarations. The linker will enforce this.

HTH,
Michiel Salters

 

[puzzlecracker]

Read 7.1.1/7 - "The linkages implied by successive declarations for a given
entity shall agree. That is, within a given scope, each declaration
declaring the same object name or the same overloading of a function name
shall imply the same linkage. Each function in a given set of overloaded
functions can have a different linkage, however."


Yes. The examples given are -

static int a; // a has internal linkage
int a; // error: two definitions

static int b; // b has internal linkage
extern int b; // b still has internal linkage

int c; // c has external linkage
static int c; // error: inconsistent linkage

extern int d; // d has external linkage
static int d; // error: inconsistent linkage

Sharad

'7.1.1/7' - where is it? in FAQ? couldnt find it there even slightly
related to the linkage. Could you please link me to it?

By the way, thanks for your kind help!

 

[Sharad Kala]

'7.1.1/7' - where is it? in FAQ? couldnt find it there even slightly
related to the linkage. Could you please link me to it?

My bad, I must have explicitly said that I was making reference to the Holy
Standard ISO/IEC (14882:2003). I sometimes take things to be self
explanatory

By the way, thanks for your kind help!

You are quite welcome.

Sharad