Class VERSUS namespace, OR class AND namespace? [closed]

Answer 1

Separate Foo_Class and Foo_Namespace is definitely wrong, it will prevent you from using Argument Dependent Lookup to find functions in the namespace that are meant to be used with the class.

So the class should be nested within the namespace if there will be functions in the namespace taking arguments of the class type.

Using the same name for the class and namespace is a bit confusing, possibly leading to ambiguities in some cases.

It's also unusual to name a namespace with an initial uppercase letter. If your class names start with an uppercase letter you could go for namespace foo and a class Foo, giving foo::Foo.

Is the namespace not going to contain more than one class? That sounds unusual to me. I would name the namespace after all its contents, just not one type. If it's a socket class I'd put it in a networking namespace, for instance.

I think _c suffixes on classes is completely ridiculous. I don't like the _ns suffix on namespaces either, its only saving grace would be that Foo_ns::Foo is better than Foo::Foo but I'd still make it foo::Foo instead.

(The rest of your question just seems to be "why are namespaces good" which shouldn't really need explaining, they were added to the language for a reason, and the good advice to use non-members for parts of the interface which don't need to be members. Google are right, in general use headers not forward declarations, that doesn't change the fact that you can re-open namespaces in separate headers to add new names to the namespace, which is the advantage you're describing.)

Answer 2

I recommend having your class in a namespace with related functions. A big reason for this is argument-dependent lookup (ADL). When you call a non-member function that has a class type argument, the function name is looked up in the enclosing namespace of that class. So if you have, say:

namespace foo {
  class bar { };
  void baz(bar);
}

If you ever want to call baz, you won't need to explicitly give the namespace it is contained in, you can simply do:

foo::bar x;
baz(x);

Without qualifying baz, the compiler still found the function because it is within a namespace that encloses the type of its argument. In this way, C++ considers the contents of the enclosing namespace of a class to be part of the interface of that class. Implementing functions that are part of the interface of a class as non-member non-friend functions in this way, allowing ADL to find the function, increases encapsulation. If a function doesn't need access to the internals of a class, don't make it a member of that class - instead, put it in the same namespace as that class.

It's suspicious that your namespace has the same name as your class, however. Usually there will be more than one class within a namespace, and even if there weren't, the names would be different. The name of the namespace should describe its contents, not just the single class inside it.

Answer 3

I dislike "fractal" names repeating things and try to avoid it. For your case, I'd try something like namespace "Foo" and nested class "Type". Maybe some other name would be more appropriate, but that depends on your actual use case. Here's a use case that I find myself repeating over and over:

namespace status {
    enum type {
        invalid,
        okay,
        on_fire
    };
    // debug output helper
    char const* to_string(type t);
}

The enumeration type is called status::type, which can take values like status::okay. Pretty readable IMHO.