Internal linkage in .cpp files: why bother?

[cmc5788]

Hi,

I'm still grappling with the concepts of linkage and memory management. I'm from a Java/C# background, so I'm used to static classes, and I'm trying to make the transition to namespaces where appropriate.

So I was reading up on the use of "private/helper" functions for namespaces being defined within an anonymous namespace to force internal linkage.

My question is this: what's the point of forcing internal as opposed to external linkage if these functions are defined in a .cpp file? Clients of the namespace will be including the header file, so anything of global scope declared/defined in the .cpp shouldn't be visible anyhow, right? Why bother with the anonymous namespace trick at all, in this case?

[laserlight]

My question is this: what's the point of forcing internal as opposed to external linkage if these functions are defined in a .cpp file? Clients of the namespace will be including the header file, so anything of global scope declared/defined in the .cpp shouldn't be visible anyhow, right?

But they could say, define a function with the same name, in which case the external linkage would mean a linker error as the function would appear to have been defined in each translation unit. Alternatively, a smart alec who sees that such a function is defined could declare the function and then use it, and then complain after you remove the function during some refactoring.

[cmc5788]

But they could say, define a function with the same name, in which case the external linkage would mean a linker error as the function would appear to have been defined in each translation unit. Alternatively, a smart alec who sees that such a function is defined could declare the function and then use it, and then complain after you remove the function during some refactoring.

Ah, I guess I didn't think of it that way. Thanks for the response

[Peter_APIIT]

Summary from laserlight opinion is name crash.