Qt Development – Prefer Qt Functions, Data Types, and Classes

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

• gets 0 to N inputs,
• returns 0 or 1 result (possible a composite or collection),

• and isn't tied to state.

  

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

• My function shall be:
  • short,
  • side-effects free,
  • realizing one and one function only.
• My function shall be strict on output. ^[1]
• My function shall be testable, and tested.
• My function shall be readable and read like a natural language expression.
• My function shall be documented. ^[2]
• My function shall be null-hostile.

^{[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.}

Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

In older C++ (pre C++11), there is no significant difference between your two implementations of operator+. Either the copy constructor gets called when you invoke the operator or when you make the explicit copy inside the operator.
In this case, it is more of a personal preference/coding guideline issue which one to choose.

With the introduction of move constructors in C++11, the pass-by-value case has gained an advantage, because that allows the parameter to be constructed using either the copy constructor or the move constructor, depending on what the operator is being invoked with.
For your Vec3i class, the difference is not that big, but if you have classes that maintain dynamically allocated resources, the proper use of move constructors can significantly reduce the amount of memory that your application needs.