Did you know that there are three different C++ namespace types? Namespaces, which are simple to learn and apply, offer a clever means of packaging your code and can assist when symbol conflicts occur. And how well does your code handle exceptions? Inserting exception-handling code can make your code more ready for packaging as external functions. Stephen Morris contends that just as namespaces offer an efficient way to package code, the skillful use of exception handling can quickly simplify that code.
C++ Modularity with Namespaces and Exception Handling
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Quite nice article. I didn’t know about unnamed namespaces, though
Just yesterday i stopped using namespaces in my personal project and began using a prefix on all my classes instead. I think the code is much cleaner and easier to read now, without that extra indentation. In addition to that the code always communicates what “namespace” the class comes from. I will alwo stop using most of my nested classes for the same reason, I had trouble reading my own code.
I don’t think a prefix will icrease the risk of name collision much. Usually namespace names are longer than a prefix but even a namespace can happen to have the same name as another namespace.
Namespaces are usefull when you writes libraries, to avoid collisions with existing code or future others liraries used in your project and not collision within your project.
But do not forget that namespaces make modularity easier than prefixing. If you want to change the whole code but keeping the same interfaces, you will be able to switch from one to another only with a modification of the namespaces of your “using” statements. That enable you to keep old and new code side by side in your project, and with modification of a simple line – in each file.
Namespaces are probably better in really large projects because it is easier to change a namespace than having to rename all classes. I never worked on a really large project yet but for now I think a prefix works just fine.
The problem was that I had classes with the same name but with different functionality and I was using namespaces to keep tham apart. I felt the code became much less cluttered and readability was increased with prefixes. Good code communication is an important point too. I think it is a similar reason to why some people prefer some form of Hungarian notation.
This is my conclution:
Prefixes – Readability – Classes with same names but different semantics and interfaces
Namespaces – Modularity – Classes with same names, sematics and interface
Just yesterday i stopped using namespaces in my personal project and began using a prefix on all my classes instead. I think the code is much cleaner and easier to read now, without that extra indentation.
Well, you don’t have to indent the body of a namespace, if it makes such a difference to you.
In addition to that the code always communicates what “namespace” the class comes from.
That’s what the :: syntax is for. Shame C++ doesn’t (or couldn’t?) use a single dot instead of the double colon, but foo::bar still isn’t really more bother than foo_bar.
“using namespace” may be convenient when writing code, but it should be used carefully because it might cause confusion when reading the code.
I try to avoid the using statement too so I can see all the time where a class comes from. But I wasn’t using it for classes within the same namespace, of course. Still, I didn’t like it much.
I know I don’t have to indent everything, but the code formatter to. I guess I just don’t like C++’ syntax. The following would have been a nicer way to write:
class ns::Classname
{
};
Forward decarations to different namespaces are ugly too.
namespace nsa
{
….class ClassA;
}
namespace nsb
{
….class ClassB
….{
……..nsa::ClassA* m_a;
….}
}
alternatively. better or worse?
namespace nsb
{
class ClassB
{
….nsa::ClassA* m_a;
}
}
It seems like I am a C++ hater but maybe I am back to namespaces again next week. By the way, the D language has a much nicer syntax than C++, but I have not tried it yet.
You know that you can create aliases for existing namespaces, right? E.g., if you have the foo::bar::baz namespace, and you have to type it multiple times, instead of an ‘using namespace’ directive you can do:
namespace fbb = foo::bar::baz;
From there on, fbb is the same as foo::bar::baz, which saves typing. If you are careful enough choosing your aliases, code is still clear and easier to read.
From a pragmatical point view, I preffer prefixed namespaces over C++ ones. An example:
If I look on the internet for NSObject (NextStep Object class used in Cocoa), I’ll find any reference to it. Yes, there are some gotchas – for example part of the Mozilla classes are also prefixed NS (“ns”), like nsComPtr or similliar.
But let’s say that was just Object, not NSObject, and let’s say it was put in a namespace called “NS”. I’m sure that if that was the case, and if you did “NS::Object” you’ll not find all reference to code and data using it, because the latter most of the time would simply import, e.g. “using namespace NS”, and later use Object.
Same goes for for foreign source code, e.g. not written by you. It’s easier to analyze it if you know all symbols, not to guess – this symbols comes from this namespace or the other names.
And another thingie. What if you decide to export your functions to a scripting language? What if that scripting language does not have namespace support, and even if it did, it’s not using “::”, but say “.” or something else (“_”). Well you’ll end up with different documentation, and the same “google-or-anything-else-search” problem.
It would’ve been good, if the UNIX guys long time ago knew about this, and prefixed every core os function like that – like OSFileOpen, instead of fopen, etc.
So my three points for prefixed namespaces:
1. Easier to find documentation, outside the provided one.
2. Easier to port, or keep bindings, to another language, which might or might not have namespaces support, or it’s namespace support might require different syntax.
3. Easier to understand foreign to you code, or lookup in that code for other refferences of the said functions, classes, variables, enums, etc.
Edited 2006-03-06 17:27
I prefer
class GEOMPoint;
rather than
namespace geom {
class Point;
};
the idea of a prefix to classes was given to me by Large-Scale C++ Software Design by John Lakos (1999).
Also if NSObject is developed by Apple and NSObject by Mozilla too well here namespace can be used to distinguish them !
Also when you have this:
void DRWGraphics::drawLine(const GEOMPoint& p1, const GEOMPoint& p2, const DRWColor& color);
is better reading than
void Graphics::drawLine(const Point& p1, const Point& p2, const Color& color);
because you can see what package a class, such as Point, belong to.
I agree, though, that the day you will move GEOMPoint to DRWPoint you will have to change the source code on many parts.
I’m using the prefix way, though.
Edited 2006-03-07 07:51
>The advent of XML has highlighted the importance of namespaces in the data domain.
No, the importance of namespaces was well highlighted in the literature prior to the advent of the TFH (TLA From Hell).
http://lambda-the-ultimate.org
Every improvement in coding practice has been met with criticism, especially about speed of execution.
Exception handling is just the next battle ground, except that C++ has been successfully using exception handling for 15 years.
If speed were our only criteria we’d be writing in x86 assembler, and maybe the OS guys Should Be.
But for business software exception handling makes code bullet proof. Even Microsoft is coming on board!
http://research.microsoft.com/specsharp/
http://research.microsoft.com/specsharp/
Though exceptions are nice, Spec# (a research project extending C#) goes much further, doing pretty advanced static checking of code properties. Think “Design By Contract”, verified by an automatic theorem prover.
A similar tool, for Java:
http://kindsoftware.com/products/opensource/ESCJava2/
…IMHO.
1. The author fails to mention the fundamental namespace ‘std::’ and how it has improved things (over the global namespace) since it was introduced.
2. No mention is made of the confusion that can potentially arise from ‘using namespace XXX’ statements and in particular, the bad practice of using them in headers.
3. The code examples are badly formatted.
However, I appreciate the benefits of namespace usage and will no longer program with prefixes. I came to this conclusion some time ago, due to various sources, but I’m sure if I had read this article at the time it would hardly have helped to influence my decision in favour of namespaces.
Edited 2006-03-06 18:54
I used to be in the same camp with the prefix guys of this discussion.
The matter of fact is that namespaces do help when you write a project no matter whether or not it is big or small. It helps when you are bringing along your own toolbox that you wish to re-use from app to app and it helps when you are part of one of the teams that are doing development. It is a good coding practice if you are using C++
Whether or not it is convenient to read is a different issue. At the end of the day, if the namespace is well incorporated in a coding standard that is “enforced” on you, you have no choice than following it 🙂