CML - The Configurable Math Library

CMakeLists.txt should be cleaned up using more modern CMake functionality, including adding installation support for easier vcpkg integration (#22) and adding relevant target_compile_features(...) (#29).

The AppVeyor configuration should be modified to use the Ninja generator for CMake going forward, as this will greatly simplify the YAML, and Ninja is more efficient than using Visual Studio directly.

It's possible that vcvars64.bat may need to be called to ensure Visual Studio 2017 builds use the x64 toolset.

Rather than rely on macros in compiler.h for feature requirements, use __cpp_* preprocessor directives to detect requirements, and error when not met.

Support for these directives requires a recent compiler. See .appveyor.yml for the current list.

Replaces issue #28.

compiler.h has no annotations or comments to make it clear that the macros in the file are for internal use only. This is confusing, and can lead to unexpected broken builds (e.g. due to removing CML_CONSTEXPR in a previous commit).

compiler.h should be updated to use __has_feature() when building with Clang. This should help work around AppleClang/normal Clang version ambiguities.

It would be useful to support C++17 structured binding to the elements of a fixed-size cml::vector<>. For example:

auto [x,y,z] = cml::vector3d(1.,2.,3.);

should yield

x = 1.
y = 2.
z = 3.

VS2015 doesn't like passing parameter packs to non-packed arguments, which affects rebind_alloc in particular. The quick fix is to cater to the common case of a single rebind argument.

The default constructor for fixed<..., external> is disabled if the compiler does not support rvalue-ref-from-this. This is too strict, however, and prevents creating arrays of external<> vectors when compiling with e.g. VS2013.

Approx().epsilon(e) from Catch interprets e differently from the tolerance T in BOOST_CHECK_CLOSE(...). In particular, e is interpreted as maximum relative difference, whereas T is interpreted as relative error. e effectively tolerances the number of significant digits, and therefore tests must be updated to use a smaller value, in general.

From CML1 created by demianmnave : demianmnave/CML1#8

Use CATCH instead of the Boost.UTF for the test rig. This will simplify user requirements, as well as reduce the complexity of the AppVeyor and Travis CI configurations.

From CML1 created by demianmnave : demianmnave/CML1#6

CML2 is not tested for XCode, but should at least be made to recognize clang 3.6 and 3.7, as well as XCode versions that match particular clang versions, starting with XCode 7.0. The XCode CI support offered by Travis CI may be a big help for this task.

• [x] Build against clang 3.6 (also use Travis CI?)
• [x] Build against clang 3.7 (also use Travis CI?)
• [x] Setup Travis CI to build CML2 against XCode 7.3

Requested by: @Segmented See also: #5

New compiler support requirements obviate the need for most feature macros (see README.md and target_compile_features(...) in CML.cmake):

CML_HAS_DEFAULTED_MOVE_CONSTRUCTOR
CML_HAS_MSVC_BRAIN_DEAD_ASSIGNMENT_OVERLOADS
CML_HAS_MSVC_WONKY_PARAMETER_PACK
CML_HAS_RVALUE_REFERENCE_FROM_THIS

Removing the #ifdef blocks associated with these macros will greatly simplify the code.

CML matrix multiplication is based on naive algorithm which does not take into account any cache memory optimizations. As the result matrix multiplications becomes bottleneck in any real-world applications using CML. It would be nice to implement at least some memory optimizations (https://gist.github.com/nadavrot/5b35d44e8ba3dd718e595e40184d03f0). Also it would be great to use SIMD intrinsics (https://codereview.stackexchange.com/questions/101144/simd-matrix-multiplication) if not too hard to implement in template code.

From CML1 created by demianmnave : demianmnave/CML1#11

In addition to this:

matrix44f_r m; 
matrix_rotation_world_x(m, angle); 

support this:

auto m = matrix_rotation_world_x(angle);

This should be fast (enough) with current compilers.

From CML1 created by demianmnave : demianmnave/CML1#4

Constructing a matrix using initializer_list syntax would be natural and pretty convenient, e.g.:

matrix33d M({ { 1., 2., 3. }, { 4., 5., 6. }, { 7., 8., 9. } });

or

matrixd M = { { 1., 2., 3. }, { 4., 5., 6. }, { 7., 8., 9. } };