Thread: Understanding Linkage

The following is my self-adopted policy on each translation unit not implementing a class:

Code:

#include /*...*/
 
/* -- declarations ---------- */
 
void f(); 
void b();
 
namespace {
  void foo();
  void bar();
}
 
extern void faz();
extern void baz();
 
/* -- implementation -------- */
 
void f() {/*...*/}
void b() {/*...*/}
 
namespace {
  void foo() {/*...*/}
  int bar() {/*...*/}
}
 
/* -- EOF ------------------- */

- f() and b() are entry points to this unit. They are called by some other unit(s) and defined here.
- foo() and bar() are only called within this unit (possibly from f() or b()).
- faz() and baz() are called in this unit, but defined elsewhere.

This is basically how I structure most of my files. Every function is declared and I make sure everything that can be declared local to the unit, is made so. However I have a few questions:

- If, for some reason, I want to move those declarations to a header file I will have to keep the unnamed namespace in the header file, otherwise the linker will complain. However, I shouldn't be using unnamed namespaces in header files. Is it ok to keep an unnamed namespace in a header file when I know that header file is not going to be included by any other module?

- As I understand, my usage of the extern keyword above is unnecessary. Functions have external linkage by default. However I find it has a documenting quality to it. At just a glance I know those two functions aren't defined in this unit. Is there any downside to this approach, or can I keep it?

- I'm being told some modern(!) debugers depend tremendously on external symbols. I don't see that happening so far on my implementation (mingw with gdb) when I replace the unnamed namespaces by the deprecated static declarations. But still, do unnamed namespaces circumvent this problem on debugers that may experience it?

Originally Posted by Mario F.

- If, for some reason, I want to move those declarations to a header file I will have to keep the unnamed namespace in the header file, otherwise the linker will complain. However, I shouldn't be using unnamed namespaces in header files. Is it ok to keep an unnamed namespace in a header file when I know that header file is not going to be included by any other module?

I am always wary of "I know that header file is not going to be included" kind of statements. You never know what will happen in the future. why can't you just leave the unnamed namespace declarations in the source file? If they are local to a particular translation unit, why bother exposing them at all?

Originally Posted by Mario F.

- As I understand, my usage of the extern keyword above is unnecessary. Functions have external linkage by default. However I find it has a documenting quality to it. At just a glance I know those two functions aren't defined in this unit. Is there any downside to this approach, or can I keep it?

There isn't any downside (apart from 7 extra keystrokes ) that I can see.

Originally Posted by Mario F.

- faz() and baz() are called in this unit, but defined elsewhere.

This part is a bad idea. There should be a header associated with the "elsewhere" which contains the symbols meant for external use. Include this header and forget about the private declarations.

This also gets rid of the case you're documenting with the redundant extern keyword.

Okies. Thanks for the input. Will do as suggested; as I understand it, external declarations going into a header file and local ones staying with the cpp file.