Use move for std::vector instead of copying in path functions

[bobtista]

• Closes Consider moving std::vector instead of copying the data #1891

Refactors path-following functions to use move when transferring std::vector<Coord3D> ownership

Changes:

• Updated aiFollowExitProductionPath and aiFollowPath inline functions to accept non-const vector pointers and use std::move
• Modified AIStateMachine::setGoalPath to move the vector instead of copying
• Updated privateFollowPath and doQuickExit signatures to support move semantics

[xezon]

Did you check that the passed vector is never used after it is consumed?

[bobtista]

Did you check that the passed vector is never used after it is consumed?

Looking at call sites, they all pass local vectors (exitPath, path) that are not used after the function call. They go out of scope immediately, so this is safe, right?

[xezon]

Yes, when the std::vector contents are not used anymore after they are now consumed by the functions then this is safe.

[xezon]

What is going on with the const_cast here? This looks dangerous. Can we get rid of it?

[bobtista]

Yeah, it can be mutable. Another option maybe we change aiDoCommand to take non-const pointer, but that changes more stuff. I set it to mutable.

[xezon]

That is not so elegant either.

The problem looks to be that AICommandParms is passed as const to aiDoCommand functions. I suspect we need another change and pass it as non const, UNLESS there is a very good reason why we cannot consume these structures.

This would also allow to optimize this call:

m_pendingCommand.store(*parms)

It currently creates a copy of the whole thing, instead of swapping/moving it.

Perhaps we need another change, refactoring aiDoCommand first, then optimize m_pendingCommand and this change.

[bobtista]

#1924, and I used a script to replicate to generals :)

[xezon]

That is not so elegant either.

The problem looks to be that AICommandParms is passed as const to aiDoCommand functions. I suspect we need another change and pass it as non const, UNLESS there is a very good reason why we cannot consume these structures.

This would also allow to optimize this call:

m_pendingCommand.store(*parms)

It currently creates a copy of the whole thing, instead of swapping/moving it.

Perhaps we need another change, refactoring aiDoCommand first, then optimize m_pendingCommand and this change.