Well, people are different. I care a lot about the structure of my code. I care about making it logical, consistent and clean. I like to keep things systematic and organized. I like my code to reflect / represent some mental image / model I have of the overall architecture and program flow, and thus be able to navigate intuitively around it (precisely so I don't have to search
so much for stuff).
If you prefer to have your things randomly strewn around and also happen to willy-nilly switch things in and out of "static" status on a regular basis, then obviously having to cut and paste and wade through everything, looking for the end of the file / namespace each time is a huge, huge ordeal that I wouldn't wish upon my worst enemy (and certainly not someone with such a low suicide threshold).
True, I do work in Visual Studio (with a couple of helpful add-ins), which among other things allows me to collapse functions (and namespaces) and view thousands of lines of code as a handful of lines - much like the pseudo-code in my previous post - in a way that gives me a nice overview of the whole file. And from that vantage point I can quite easily select, cut, paste and move large chunks of code wherever I want, so for me those things are just less traumatic to accomplish, I guess.
Here's how a 1391 line file looks to me in a couple of mouse clicks:
I say that beats nexting through a bunch of grep hits in a wall of text any day of the week.
Anyway, I already granted the kind of case you speak of with lots of internal / external interleaving as one where a single anonymous namespace probably isn't the way to go. But then I went on to say that when "static" is the rule and a few odd external functions are the exception, then it might simply be easier to just work inside the namespace and put / hoist one or two things outside of it, once in a blue moon, when you know they need to be externally accessible.
Again, the premise here is a codebase where most functions would be "internal" anyway (though I was under the impression that that was the case with HMH).
Regarding the mapping: I wasn't referring to where functions are in relation to each other in the file (although personally I do consider that when I organize my code). I was referring to having everything internal grouped together in one section and everything exposed externally grouped together in another (i.e. outside the namespace). And since the former would then be "internal" to that namespace and the rest "external" to it, it would map - as in correspond - nicely onto them being internal / external to the translation unit as a whole.
And I think you misunderstood the point about search. What I meant was that you don't need to search
for "internal" functions when using an anonymous namespace
; all the internal functions are in it and the external ones are not! It's like having an already sorted list of internal and external functions.
How you can trivially verify that Foo() and Bar() are internal and Baz() is external? Well, for one, Foo() and Bar() are indented, and Baz() isn't. Or, in my case, I could just collapse the namespace and see Baz() hanging on the outside. Plus having some intuitive notion about where and how things are placed in the code in general also helps (another reason I like to have a solid, consistent structure behind what I do).
Why would you want to search? So you can absolutely be sure that whatever you wanted to be external linkage is external
So how do you search for externals
? That was my point.
Bottom line is that nobody is trying to force you
to do things differently. I was just pointing out that in certain cases, especially ones where most
functions are internal anyway, it might be an alternative to simply "work inside" an anonymous namespace and keep that one export on the outside.
EDIT: Apparently, you can keep extern "C"
declarations like GAME_UPDATE_AND_RENDER inside the namespace and still have them externally visible. More details: http://www.comeaucomputing.com/techtalk/#nostatic