You can also put this using inside a class / struct or namespace in the header file:

namespace C33
{
	using Vec3 = Vectormath::Aos::Vector3;

	inline const Vec3 square (const Vec3 &v)
	{
		return mulPerElem(v,v);
	}

(Well, at least to me that's something new i've figured out only recently.)

Put your entire engine into the same namespace. That way you avoid name collisions while having to use ::.

Hi @fleabay , mind me asking why are you getting rid of GLM?

I personally dislike namespaces. This is mainly because more than once I have seen people name stuff things like “Camera” in a their own namespace and then use some 3rd party library with it's own “Camera” and there is still a conflict. My friend recently brought a bug to me that was caused by this exact issue. He was banging his head for a couple hours trying to figure out what was going on.

That being said v1, v2, v3 etc. sounds like it's pushing it a bit. Oddly enough you might get away with it only because nobody else is crazy enough do it ?. In my code I have some sequence of capital letters that prefixes anything that's global and that's served me well (so far). This is probably because I rarely use global anything so nearly everything I have to worry about is a class name which tend to have longer names anyway. In general I don't like to put a lot of common names in global space, but again if you're the only one doing it, you'll probably get away with it.

Gnollrunner said:
I personally dislike namespaces. This is mainly because more than once I have seen people name stuff things like “Camera” in a their own namespace and then use some 3rd party library with it's own “Camera” and there is still a conflict.

But that's what's solved by this:

a light breeze said:
Put your entire engine into the same namespace.

Though, seems everybody is using just 2 letters for engine namespaces, so… : )

Personally i like it a lot. I use namespaces hierarchically, e.g. MeshProcessing::VectorFieldDesign::GenerateCurvatureField(). It's some typing, but i can see dependencies without looking for includes, and i can find functionality easy from Intellisense while typing.
Also VectorFieldDesign is just some functionality and has no member data or need for private functions, so no need for a class, and using a namespace still allows to group this stuff together then.

It's also especially useful when working with multiple math libs, or replacing one by another. I would not recommend to have only one common namespace. Vector and Matrix stuff is the most annoying issue for programming in general for me. Use 3 or 4 floats for a vec3? Use 4x4 or 3x4 for a transform? Need mat4x4 still anyways? To SIMD or not to SIMD? Template for float and double?
After decades i still can't answer any of those questions in general, and it remains probable replacement all the time.

SuperVGA said:
mind me asking why are you getting rid of GLM?

One argument may be performance: https://www.gamedev.net/forums/topic/709305-glm-vs-vs2019-for-simd/

JoeJ said:

Gnollrunner said:
I personally dislike namespaces. This is mainly because more than once I have seen people name stuff things like “Camera” in a their own namespace and then use some 3rd party library with it's own “Camera” and there is still a conflict.

But that's what's solved by this:

a light breeze said:
Put your entire engine into the same namespace.

That's the idea at least, however some people tend to OD on using statements and then things can get confusing. I've seen seen code compile and then link to the wrong routine if the arguments happen to be close enough (i.e. my friends problem above). A namespace is more or less like having an extra long name, but if you put ‘using’ everywhere that goes away, so it's of dubious value at that point. Note that many people consider it bad practice to use “using namespace std;”. The same logic that goes behind that decision can also be applied to other namespaces.

Gnollrunner said:
A namespace is more or less like having an extra long name

Not if you treat it more like a path, like directories to files. It's a hierarchy then, which can be useful to organize stuff. Long names couldn't do this.

But agree otherwise, i'm using ‘using’ only for core stuff like vec3, but not for STL.

Gnollrunner said:

A namespace is more or less like having an extra long name, but if you put ‘using’ everywhere that goes away, so it's of dubious value at that point.

“Using proper looping constructs is more or less like having structured code, but if you put ‘goto’ everywhere that goes away, so it's of dubious value at that point.”

Don't do that. There are some valid uses for ‘using namespace’, just like there are some valid uses for 'goto', but they're extremely rare (and always local to a specific function).

a light breeze said:

Gnollrunner said:

A namespace is more or less like having an extra long name, but if you put ‘using’ everywhere that goes away, so it's of dubious value at that point.

“Using proper looping constructs is more or less like having structured code, but if you put ‘goto’ everywhere that goes away, so it's of dubious value at that point.”

Don't do that. There are some valid uses for ‘using namespace’, just like there are some valid uses for 'goto', but they're extremely rare (and always local to a specific function).

I guess the point is, you either have to type long names, or you increase your risk of a collision with ‘using'. If you didn't have namespaces you could always make up your own prefix which is basically what I do, or use statics in classes which is what some people used to do before namespaces were added to the language. In any case I find I don't need them. If they work for you then great.