Programming
SDxWiki

Discussions on details of programming, not SDx-specific.

(Or, A Sheltered Alternative To Getting Flamed On A Public Newsgroup)

DJH Interesting. I remember once asking someone why he was wrapping an entire API behind a namespace. He seemed baffled that I would ask such a question (the answer is, to a certain degree, patently obvious) and started explaining what namespaces do. I interrupted and clarified my question to be "yes, I know what a namespace is; why bother? This isn't being released as a 3rd-party library, and even if it was, namespace clashes are rare and fairly easy to get around." We agreed to disagree on the importance of the namespace (it wasn't a hot button for me, anyway), and on those rare occasions when Greg lets me work on the goal he assigned to me during my review, I type "using namespace CsiDb" at the top of my source file. :-)

DWM I resemble that remark. :-) You were much more diplomatic about it than Nandor was!

By way of elaborating on that long-ago discussion: It was my hope that CsiDb would eventually also be used by other groups within the company, hence it does in a sense qualify as a third-party library.

I eventually found the entire thread that Meyer's post spawned, and most people seem to disagree with him. He's made me rethink the issue, but not change my mind as yet. I'm sure you'll be happy to learn that I'm at least consistent, and the first bits of SDx physical simulator code are safely wrapped in namespace SDxPSim. ;-)

JDH I just love Scott Meyers (perhaps it's his hairstyle?) - trouble is I only understand about half of that article. And the half I do understand I don't agree with. The easy half appears to be "I don't like namespaces because you have to type using namespace Blah alot" - that doesn't seem like a bad trade-off instead of having to mangle every name with a "somewhat redundant" prefix e.g. CsiDbFunction1(), CsiDbFunction2(), CsiDbFunction3WithAReallyLongName() - yuck! He's also not very consistant with the name mangling argument - at first he suggests you don't even really need to mangle the names because namespace clashes don't really happen all that often - but then touts name mangling as a low cost and portable solution. So which is it? Do you need to mangle some names but not others? How do you decide? I'm tempted to sue him for the comment that clashes don't happen often - I shouldn't have to be creative with names because a name such as "fill()" is already in use (although I'd obviously choose phil() instead). So, to this part of the argument I say phooey! Use namespaces you slackers (and while you're at it did I ever mention the fact that I like Hungarian notation...)

Now as for the half I don't understand - that sounds much more sinister and like it might be a very sound reason for ditching namespaces as a "failed experiment". I confess I don't understand the issues of Koenig lookup confusing namespaces - it might be more accurate (and kinder to the ego) to say that I haven't spent the time to try and understand the issue. However, I do very much understand his brief history of namespaces. It's very important (and I hazard to say quite rare) to remove "failed experiments" to avoid patching problems and ending up creating a monster.

I would humbly suggest that Dave's objection of namespaces which he raised with an unidentified colleague was based around the arguments in the first half - so I would side with my esteemed anonymous colleague. To answer "why bother" I would say because it's good practice (that's obviously my opinion!), it doesn't cost a lot and you don't know what the future might bring (and retrofitting would be a royal pain in the butt). Now if Dave's concern was over issues with Koenig lookup then I most humbly apologize and I'd like to ask for an explanation that this dumb Java programmer could understand...

;-)

DJH My objection was not even an objection. I don't object to namespaces, and have been known to use them for my own nefarious purposes. The conversation with the unnamed colleague was less an objection and more that I didn't see any real need to encapsulate CsiDb in a big ol' namespace. (Did I mention it wasn't a hot button for me?) Good practice? Perhaps. Necessary in this case? Perhaps not. (/me shrugs because it's really not a hot button for him.)

DWM David was right about our original discussion: I was baffled by his question, which was a good indication that I hadn't thought about it deeply enough. And I probably did start rattling off Namespaces 101 while my brain was backpedalling. :-)

If you have an hour to kill, go hunt down the actual newsgroup thread, it sounds a lot like this one. :-) This topic seems to be right up there with code formatting and naming conventions.

Meyers does bring up some good points. I find that I often insert "using" directives, and that seems like a step backwards. OTOH, what namespaces do give you are useable tools for dealing with conflicts when and if they arrive. Just yesterday evening (while working on, dare I say, SpookyDistance code) I ran into a real-world conflict between two third-party libraries that wouldn't have happened if some library designers had made use of namespaces. Apparently, the standard C++ libraries that come with gcc 2.95.mumble (at least in the MinGW distrib) include some extensions that are not in a namespace. One of the other libraries I'm using, uBLAS, defines a conflicting identifer: 'slice'. (It's a class used to specify a slice through a vector or a matrix.) Luckily, I was intending to build with STLport, which doesn't have this problem. I only noticed this while I was fumbling around getting my build configuration to work, which wasn't picking up STLport. If I wasn't using STLport, though, the uBLAS namespace would have allowed me to work around the problem. (Interstingly, the uBLAS namespace is actually nested deeply in boost as boost::numeric::ublas. I'm not very comfortable with this deep nesting strategy, which is what set me off on the Web search which found the article in the first place.)

Regarding Koenig lookup: I've looked at it, but it's not the sort of thing that sticks in my head. As I understand it, the problems have to do with looking up symbols referenced by template code. Koenig lookup defines the involvement of the template code's original namespace vis-a-vis the instantiator's namespace environment and the namespaces of other types introduced by the template parameters, etc. etc. Apparently, user's expectations can vary, making it really hard for library designers to choose between explicitly qualifying everything, or leaving things unqualified so that user-defined symbols can be referenced by instantiations. And as always with current compiler technology, the error messages that appear when things go awry are more voluminous than your source code, and only slightly more legible. :-)

JDH Excuse my poor attempt at humor (I was trying to follow in Dave's vein and I may have misjudged). Good point - it wasn't an objection on Dave's part so I overstated that. It's not a hot button issue for me either - I just like arguing (c'mon - you all know me at least that well (Istvan aside)). I just think it's a good naming style and one that the cost isn't high. I consider it an investment for the future much like any other "good practice" (appropriate commentary, useful names etc.) I don't see the insertion of "using namespace blah" in a cpp file as a particularly retrograde step (of course putting it in a h file is kind of dumb - and I remember Dan pointing this out to the team during my time on CsiDb).

What I wanted to highlight (and probably failed due to my (purposefully) locquacious(sp?) style) was that while I think namespace is a useful naming tool its hidden cost may well be too high because of Koenig lookup issues. I think that's the much more important part of Meyers' article and one that didn't seem to be being considered in the first two posts. Furthermore the first part of the debate is much more a question of personal style and thus is a debate that can go on forever - some people like coding style X some people hate it and many others merely have no objection to it (and thus no great desire to use it or not). Whereas the second part of the debate would appear to offer a much more tangible reason (perhaps less intangible would be a better characterization) as to a hidden "evil side" to namespace usage.

Just my five dollars worth ...

DWM Sorry if that came across as disgruntled, 'cos I wasn't. (It was late, maybe I just wasn't expressing myself well. Trying to be cute. Text amended.)

I think you're right, the relevant part of Meyers' article is the latter part, and that's pretty involved. In general, though, non-conformance of compilers and variations in the quality of their lookup algorithms probably makes it hard for most of us to assess whether the lookup problems are really serious or common. I know I've run into some problems of this sort with complex templates, but I'm also certain that the compiler in question wasn't using a full Koening lookup. On balance, I'm inclined to reject Meyers' view. But I don't doubt that eventually there will be a few more language additions to help deal with the corner cases, and those will probably be primarily of interest to template library developers.