Correct way to define C++ namespace methods in .cpp file

Question

Version 2 is unclear and not easy to understand because you don't know which namespace MyClass belongs to and it's just illogical (class function not in the same namespace?)

Version 1 is right because it shows that in the namespace, you are defining the function.

Version 3 is right also because you used the :: scope resolution operator to refer to the MyClass::method () in the namespace ns1. I prefer version 3.

See Namespaces (C++). This is the best way to do this.

5 years later and i thought I'd mention this, which both looks nice and is not evil

using ns1::MyClass;

void MyClass::method()
{
  // ...
}

I'm using version 4 (below) because it combines most of the advantages of version 1 (terseness of the resoective definition) and version 3 (be maximally explicit). The main disadvantage is that people aren't used to it but since I consider it technically superior to the alternatives I don't mind.

Version 4: use full qualification using namespace aliases:

#include "my-header.hpp"
namespace OI = outer::inner;
void OI::Obj::method() {
    ...
}

In my world I'm frequently using namespace aliases as everything is explicitly qualified - unless it can't (e.g. variable names) or it is a known customization point (e.g. swap() in a function template).

Googles C++ Style Guide dictates your version 1, without indentation though.

Version 3 makes the association between the class and the namespace very explicit at the expense of more typing. Version 1 avoids this but captures the association with a block. Version 2 tends to hide this so I'd avoid that one.

I choose Num.3 (a.k.a. the verbose version). It's more typing, but the intent is exact to you and to the compiler. The problem you posted as-is is actually simpler than the real world. In the real world, there are other scopes for definitions, not just class members. Your definitions aren't very complicated with classes only - because their scope is never reopened (unlike namespaces, global scope, etc.).

Num.1 this can fail with scopes other than classes - anything that can be reopened. So, you may declare a new function in a namespace using this approach, or your inlines could wind up being substituted via ODR. You will need this for some definitions (notably, template specializations).

Num.2 This is very fragile, particularly in large codebases - as headers and dependencies shift, your program will fail to compile.

Num.3 This is ideal, but a lot to type - what your intent is to define something. This does exactly that, and the compiler kicks in to make sure you've not made a mistake, a definition is not out of synch with its declaration, etc..