Well, currently the main difference is a namespace is designed to be augmented in separate files. If you try to add a new nested class to a class, you get:

test1.cpp:3:7: error: redefinition of ‘class NamespaceClass’

However, it only works that way because it was defined that way. It wouldn’t be that difficult to rework the compiler to append to a class in certain ways when it sees what is now a redefinition.

The reason they don’t is that a namespace and a class are conceptually two different things, used for different reasons. A class is meant to be instantiated, and is used to create strong cohesion between a data structure and its associated methods. A namespace is meant to loosely gather modules to make it easier to share groups of several files without causing naming clashes.

Yes, you can approximate the behavior of one using the other, but that doesn’t make them the same. If you used a redefinition-allowed class instead of namespaces, you would have problems like:

• Having to look through all header files using that class to get its entire definition, including determining if it’s instantiable or not.
• Wanting to use a name that denotes its purpose as a namespace, like StdNamespace instead of just std.
• Needing some sort of syntax to clue you in when you do accidentally redefine a class when the compiler just thinks you mean to augment it like a namespace.

When you add up all the special cases you would need to handle to make it truly follow the open-closed principle, you may as well just call it a namespace.

On top of Karl’s answer, I think there is also major semantic difference.

With namespaces, you group together related classes. This is usually goal to keep cohesion high. With nested class, the new class is primarily related to the containing class, but can be unrelated to the “sibling” nested classes.

This on top of fact that classes are meant to be instantiated but namespaces included makes them two different concepts.

A class is a definition of a type.

A namespace is a ‘container’ for a related set of these defined types.

Really two very different things serving different purposes. Just because you can mimic the use of one by using another doesn’t mean they are necessarily interchangeable.

Equally, I could use a String variable to store a number. It would, in some cases, behave the same. But it’s not conducive to good practice or even using these features as what they were originally itended for.

Well, one advantage is that you may have dozens of classes in a namespace. Have you considered what that would look like with nested classes? I mean, you can do some things with partial classes in C#, but the general case is pretty ugly. I think namespaces are there to group functionality and scope it, whereas inner classes exist to encapsulate multiple tightly-coupled pieces of functionality into one indivisible bundle.

The syntactic thing that makes the big difference is that struc-s definition aren’t addictive: they begin with { and end with } and at that point cannot be “reopened” to add other members anymore.

Namespace, conversely, can be “reopened” and extended

// file F1.h
namespace A 
{ /* some defs */ }

//file F2.h
namespace A 
{ /* some other more defs */ }

and can so be distributed on many different header each providing a closed set of classes.

If you include both F1.h anf F2.h you get all their definitions into A. This is hard (or even impossible, without convoluted preprocessing tricks) with struct & class.

On the inverse side, struct can be templetized, namespace cannot.

If classes could have been “reopened and extended” and namespaces tepletized, then the two concept will degenerate into one.

But “reopen-able classes” (think to the c# partial) due to the “inclusion text mechanism” and “multiple translation units” of C++ (that’s not a symbolic import) will lead to different translation units seeing differently defined classes. If those different translation units go to form a single artifact (a same executable) it would be not possible to define a consistent size and consistent order of members. (not that this, for namespace global variables -acting like class members in the class-namespace analogy- leads to the well known “global initialization fiasco” problem, giving an unpredictable initialization order)

Hence the need of namespace to collect names without a composition/encapsulation mechanism.

In C#, they are very similar.

namespace my_group {}

static class my_group {} // namespace

Namespaces support the using keyword and the same namespace can span multiple files, however I think they cannot be defined inside a static class.