Why do you want to make the vertex's members protected? You aren't actually hiding them in any meaningful way, with getters and setters that do nothing but that. Just make them public.

Fair enough. Thanks for your time!

I made the vertex's member variables protected simply because I could; to be OOP crazy. I only introduce the operator overloading as friends because I need to. I will not remove the accessors and mutators, because they could very easily be altered to do more than just return or alter a value.

taby said:
I made the vertex's member variables protected simply because I could; to be OOP crazy.

Omg - you are are true OOP control freak! :O You must be stopped! ; )

Remember my report about issues with the physics engine. The dev is the best programmer i know. It's surely an example of good OOP, not bad OOP. And still i got those issues due to unexpected demands on low level flexibility.

Your vertex class has the same data and functionality as a vec3.
So if it was a vec3, i would argue:
The data, and even its order in memory, is specified by conventions of linear algebra. There never will be a reason to change it. Doing so would break those assumptions related on math, and so would likely break most of your users code.
Thus there is no need for abstraction. It's the opposite: As a user of a vec3 class, i assume i can cast its memory address to an array of floats, so i can process its data easily with other code which does not use your math library.

I would not only make the data public, i would even use a struct not a class, so it's instantly clear there is no abstraction, and users do not need to read more code to confirm this.

You think overuse of auto is bad? I may agree, but it's actually just a matter of taste, and does not cause any real problems.
Contrary, abstraction can cause true limitations and problems very quickly, despite good intents or seemingly general good practice.
Protected is not as restrictive as private, but still: You cause the impression that we could (or even just always should) use those language features without deeper thought, and we would get effortless general good practice in return.
And this mindset is exactly what gave us ‘bad OOP’. That's surely not what you want to teach.

Ofc. my critique relies on the example of your vertex being a vector. Vertices are very likely customized data structures, so you can do what you want. But your student is likely unaware of that subtle difference, and likely draws those ‘bad’ conclusions.

taby said:
because they could very easily be altered to do more than just return or alter a value.

Such as? It's really just a vector type. What other functionality could you want to add to something that sets an x-coordinate?

OOP lessons should include examples of when not to use the machinery being taught. In fact, many lessons in software should include that.

Perhaps one could use std::isnan and std::isinf to help. That is, we do not follow a garbage in / garbage out paradigm, but rather a garbage in / filtered out paradigm (not sure if that's the correct wording, but I think my point is clear).

taby said:
Perhaps one could use std::isnan and std::isinf to help. That is, we do not follow a garbage in / garbage out paradigm, but rather a garbage in / filtered out paradigm (not sure if that's the correct wording, but I think my point is clear).

If you want to prevent nan propagation, a nice way is enabling floating point exceptions using _controlfp().
This way the programmer notices the cause and can make sure the case does not happen again. Very useful.
Then, before shipping the app, you could disable them.

The function can also be used to make denormals flush to zero, which could help performance.

taby said:

Perhaps one could use std::isnan and std::isinf to help. That is, we do not follow a garbage in / garbage out paradigm, but rather a garbage in / filtered out paradigm (not sure if that's the correct wording, but I think my point is clear).

I don't think detecting bad input is the responsibility of a vertex class. That should be the importer's responsibility, or the responsibility of whatever is generating the vertices. I certainly don't think it should silently fix it up at runtime. That has a performance cost (branching) and the issue should be surfaced sooner rather than later, which means crashing or doing some other kind of immediate signal the moment the bad data goes in.

NightCreature83 said:
Thats seriously up for debat if your vertex is more than POD

Which is what I'm advocating for not doing. ?

You know what I'm trying to achieve. If you can think of a better tutorial that explains the same things, then I would be most grateful.