The thing is, there is no restriction on who calls DeviceManager<VFS>::register_device. main() is able to do it.
This doesn't seem so different from:
class A { private: friend void foo(A &, B &); int x; };
class B { private: friend void foo(A &, B &); int y; };
void foo(A &a, B &b)
{
a.x = 1;
b.y = 2;
}
int main() {
A a; B b;
foo(a, b);
}
We've just obfuscated it a bit by using a template class with one function in it, and declaring that to be the friend instead of just a non-member function.
Yes, your version is what I mean by moving it to namespace scope, and it's probably what I'd do to start off with.
> there is no restriction on who calls DeviceManager<VFS>::register_device
Well, you can make it private inside DeviceManager and give the class its own friends :-))
Another benefit of my solution is that adding things to DeviceManager<VFS> doesn't require changing the VFS.h or Device.h headers at all. Anything that links these 2 classes is an entirely separate concern and very much in line with thinking in terms of models or concepts rather than types. What you want at the end of the day is an absolute bare minimum of member functions in any class.
To be honest, whatever the solution, the key is that having the Device class self-register to the VFS in its constructor (as in Andreas's blog post) is, imho, an anti-pattern and is what is really leading to this Badge mess.
This doesn't seem so different from:
We've just obfuscated it a bit by using a template class with one function in it, and declaring that to be the friend instead of just a non-member function.