Removes using namespace declarations

[OlekRaymond]

using namespace declarations can create large issues even sometimes causing a behaviour change without any warnings or messages and can promote overly verbose naming*.

* In a library named FOO a user might use FOO_Position instead of Position to avoid gdal::Position and foo::Position being unreadable.

See Jason Turner's video on the subject.

[Martchus]

Thanks - this kind of refactoring is in-line with the coding style I prefer when writing new code.

I'm only a bit unsure about avoiding these declarations for my libraries. Unfortunately I didn't choose a catchy three letter abbreviation when creating them and want to avoid breaking changes now.

[Martchus]

I'm wondering where this kind of refactoring can be automated. In theory it would be possible but I don't know any tool for this out of my head.

[OlekRaymond]

Just to keep you in the loop I doubt I'll be doing the whole codebase and these types of large foot-print refactors are better done incrementally in my experience.

I am using your repo to test my own, (because it doesn't have any package management it makes a new feature easier to test). So it's likely I'll only be changing a few files.

I didn't choose a catchy three...

That may be true but using std and CppUnit namespaces requires them too to (both) have good naming conventions and since some are in headers we also force the users to have similarly good naming conventions. It may also be worth noting that until recently CppUnit had it's own custom vectors.

The way I've done it previously has always been manual, clang tidy has a check to avoid them but no fixup. Any automated tool would suffer from the same issues the compiler does, so would get you 80% of the way there rather than 100%. This feels like something an IDE would have but I have never looked, let me know if you see anything!

[Martchus]

and these types of large foot-print refactors are better done incrementally in my experience.

True - that's why I'm also only doing this step by step, e.g. when changing code in the same class/function/file anyway.

The CppUnit adator library sounds interesting as I also still have (too) much test code using it.

[Martchus]

I doubt I'll be doing the whole codebase and these types of large foot-print refactors are better done incrementally in my experience.

I don't have a problem with merging just what you have so far. I might do a new release soon so it would probably make sense to merge your changes so far before that.

[OlekRaymond]

Should be ready to go!