Selection of libraries designed to be used with Emu projects. This was originally a Math library only, but has since been changed to hold all Emu libraries to enable consistency in changes to dependencies (such as EmuCore modifications).
Removed ability to update what a Vector references (i.e. They cannot point to different data after a call to Set anymore)
Set has been removed
Conversion Construction is now performed within the class to optimise construction performance.
Operator= will always be a copy, with moving allowed where value_type& is move-assignable, instead of moving stored_types
This provides a consistent assignment interface
Removes the ability to invalidate valid references
Removes the nip-in-the-butt scenario where one may wish to assign via a shuffled reference rvalue of the same type due to stored_type being more expensive to copy than forming references, and ends up changing references.
For example, in the old system, where std::is_same_v<Vector<4, float&>&, decltype(vec_)> == true, the statement val_ = EmuMath::Vector<4, float&>(floats[0], floats[1]. floats[2], floats[3]); would result in val_ now holding references to floats[0]:floats[3], instead of assigning its contained references.
In the new system, under the same scenario as above, the result would be similar to val_.at<0>() = floats[0]; ...; val_.at<3>() = floats[3];
Due to typical move semantics, this scenario can still result in a std::move of referenced data which may not be desirable in the stated scenari. This is a difficult one to balance due to the potential for val_ = std::move(some_other_vec_of_same_type_) which indicates an explicit desire to move. Ultimately, this will have to be worked around in a manner similar to temp_ref_of_same_type_ = make_your_ref_here(); val_ = temp_ref_of_same_type_;, which is not the most preferable solution.
A determined user could also easily implement a 'mutation' function that simply assigns value_types and never moves them, although this isn't quite as clear cut as that due to differences in how Vector arguments are handled in mutations compared to in copies. An Emu-Standardised solution is really needed for this one.
Some comments have been added to give better explanation to Vector static data, and common_vector_info has been cleaned up as none of its validity checks are used anymore.
A depth static info has been added for Vectors, which indicates how many layers of internal EmuMath Vectors they contain.
Matrix construction from conversion has been updated slightly due to more false-positive warnings from visual studio.
This was a side-effect noticed during this update, and it is unclear whether it was a side-effect of the Vector update (unlikely) or Visual Studio taking its time to decide "Actually I'll give a warning here now", the latter of which has been painfully common throughout this project.
This may be updated to be done directly within a Matrix just like with Vector, but there are no plans to do so at this moment in time.
Setanymore)Operator=will always be a copy, with moving allowed wherevalue_type&is move-assignable, instead of movingstored_typesstd::is_same_v<Vector<4, float&>&, decltype(vec_)> == true, the statementval_ = EmuMath::Vector<4, float&>(floats[0], floats[1]. floats[2], floats[3]);would result in val_ now holding references to floats[0]:floats[3], instead of assigning its contained references.val_.at<0>() = floats[0]; ...; val_.at<3>() = floats[3];val_ = std::move(some_other_vec_of_same_type_)which indicates an explicit desire to move. Ultimately, this will have to be worked around in a manner similar totemp_ref_of_same_type_ = make_your_ref_here(); val_ = temp_ref_of_same_type_;, which is not the most preferable solution.common_vector_infohas been cleaned up as none of its validity checks are used anymore.