Buddy, Can You Spare A Namespace?

C++, Namespaces, and Macros

You’re a careful C++ programmer. You use namespaces obsessively, your classes are well-organized, and your files are carefully placed in a nice hierarchy. Name collisions aren’t going to strike your code!

Well, you actually can’t guarantee that: Namespaces are completely ignored by the macro preprocessor. Short of drastic measure (such as using #undef on every symbol you use) it is impossible to tell the C++ macro preprocessor, “You cannot pass!”

C++ Compiler at Work

If a macro is defined before it reaches your class, the preprocessor will try to expand all names in your class.

Does this ever happen? Sure! For example, CLAPACK defines a macro named “max,” which finds the maximum value of two elements. The C++ standard library offers std::numerical_limits<T>::max(), which gives you the maximum value of the T datatype. In fact, CLAPACK and similar libraries can reach through time and hamper std::numerical_limits’ compilation in any project. Surprise!

One name. Two valid uses. One compiler error.

Sure, CLAPACK is a C library, and one has to make allowances for this. In lieu of function overloading, macros are the only tool for approximating generic functions. On the other hand, COME ON! Someone else is going to use the name “max.”

I don’t mean to pick on CLAPACK! It’s a nice library. I like it. In fact, there is are several C++ versions of LAPACK that alleviates this specific issue. The C version exemplifies the problem perfectly.

What’s My So-Called Point?

My point is twofold. As a minor aside, I’m disappointed that this problem isn’t being addressed in the updated C++ standard. Macro namespaces would have been a nice touch (and another 10 pages of the already-huge standard). It’s not, so I won’t dwell on it.

If that were my overall point, you would be justified in leaving me an angry blog comment telling me that this post was a waste of breath. However, this isn’t my overall point! My real overall point is that many programmers don’t take enough advantage of features offered by modern programming languages.

I admit freely that I don’t, especially for one-shot projects. Today I looked at a well-documented (but poorly designed) project I wrote in early 2007. The comments and function names were good enough that I immediately knew what was going on. I was able to use the header files within minutes.

The downside is that I could immediately see that I designed myself into several corners, the worst being a macro named “NAME”.

Why did I do this? Because none of my teachers/professors/programming books ever condemned this kind of usage. I had to figure this out gradually over time.

The Imperfect Macro Workaround

Since macro name collision is a real problem, unofficial standards have risen for dealing with macros. They can usually be summarized by a few rules:

• Use all-caps.
• Use underscores for human-readable spacing.
• Add a likely-unique prefix to your macro names.

There are a few reasons that the conventions aren’t good enough, but most of them are edge cases: You can argue that you might find two libraries that use the same prefix and define the same macros, but this is probably about as common as namespace conflicts.

The real reason that this isn’t good enough is that it’s unenforceable. Any new programmer who just learned how to use macros won’t be using the convention, and they’ll be mucking up the preprocessor with macro definitions, which will cause protons to smash, create several black holes, and destroy the universe. I should know: as I mentioned above, I’ve done it.

Old libraries will also violate the guidelines. So will people with strong opinions who think that the conventions are OBVIOUSLY trash. So will people who code at 3AM on a deadline.

“One Honking Great Idea.”

The Zen of Python is one of the great programming guides available to everyone. How do you get it? Simply type “import this” into the interpreter!

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

The last line is reflected in Python’s design: loading code from a different file automatically provides you with namespaces. This is awesome: newbies and professionals alike must use namespaces, and best of all, it’s all done transparent with respect to the programming experience.

This is not unique to Python. Modern popular programming languages offer almost-universal support for namespaces.

• Common Lisp uses packages in order to support namespaces.
• Ruby and Python use modules.
• C++ has explicit namespaces.
• Bash scripts use the uniqueness of the file system (a path points to one file).
• C uses…. name prefixes. When the programmer feels like it.

Why do all of these languages support some form of namespaces? Because name collisions really are that bad. Libraries with major name collisions simply can’t be used together, and that is NOT the aim of programming.

What Can We Do?

I find three things that ultimately help me.

1. Work with people who know a lot more than you do.
2. Learn new languages.
3. Read books written by the greats.

Right now, I have the good fortune of doing all three.

Images used in this post

“The Demon Comes” by Flickr user Islãndßoy.

Popularity: 14% [?]