You can have a look at my math library here https://github.com/godefv/math.
Unlike all other implementations I have seen, everything is generated by the library by applying operations on elementary objects. For instance, you never tell beforehand that you want to work in 3D space, you just define e1,e2,e3, and go add, multiply, or exponentiate them to produce higher-level objects. This has the advantage of factorizing a lot of code.
The library also have native support for symbolic mathematics, and that’s how expressions are best optimized at compile-time. For example, in the test https://github.com/godefv/math/blob/master/geometry/point_transform/from_vector_transform.test.cpp, the equation of a torus is computed at compile-time from a sequence (translation1,rotation1,translation2,rotation2).
Besides, I believe that the end user should never need to know about geometric algebra to do geometric computations. Therefore, I have defined some types for geometric transformations and objects (points, planes, rotations, etc). These types hide the actual implementation (I use vector geometric algebra for now, but the same API could use linear algebra, PGA, or CGA, and I am considering changing to PGA).
There is something interesting here : the composition operation uses the group operation code, the same code already used by the addition and multiplication operations. This looked appealing to me, instead of using a more complex algebra like PGA or CGA.
In a sense, I don’t need PGA as much as others because it is cheap for me to implement an additional group structure directly on geometric transformations, so translations and rotations are just generators of a group whose operation is composition. It may look like specifying this composition operation is boilerplate, but a lot of it is just specifying my high-level API which hides implementation details. But again, PGA still has some advantages, and it is already implicitly implemented, so I might switch to it internally.
Some operations are available only as functions (like reverse(X)), without a c++ operator (like ~X), because there is not a consensus on the choice of operators yet. But such a consensus would be nice. For now, the user can choose to define the operators he likes, except for the geometric product X*Y, the inner product X|Y, the exterior product X^Y, and the composition (transform1,transform2) (transform1 is applied first).
Note : another C++ library has already a topic named “GAL (C++ library)”, we might make a list somewhere.