The following is my self-adopted policy on each translation unit not implementing a class:
- f() and b() are entry points to this unit. They are called by some other unit(s) and defined here.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 ------------------- */
- 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?
