The topology class has been very easy to create and to use. Besides his utility, it has a very simple design and hasn't been a problem to be created. The two classes it contains, point_2d and point_3d, have been added to msci_units, instead of msci_geometry, because of his utility and operation with the coordinates classes. Without them here, it's needed to cross-link with the library msci_geometry, which was making building harder.
The first version of the coordinates was with one coordinates class for each system of coordinates, all inheriting from an abstract coordinate class of the same dimensions. Following that logic, the abstract coordinates classes were coordinates_1d, coordinates_2d and coordinates_3d. The inheriting coordinates classes were then cartesian_coordinates_2d, polar_coordinates, cartesian_coordinates_3d, cylindrical_coordinates, spherical_coordinates. The coordinate classes were storing the data with the variables x, y, z, p, r, theta and phi. All the functions to calculate any coordinate variable of one system from another system were available.
Also, there was a hyper_spherical_coordinates class, which was handling the sci-fi ideas related to spacetimes of more than 3 dimensions of space.
The coordinate classes were allowing to store the coordinate data in one of the coordinates objects, but it was not possible to change the coordinates class. Instead, the coordinates class was permanent in that sense, and the only way to change it was changing it inside the definition of the class the coordinates class was belonging. In order to correct that, the second version of coordinates was created. It was providing a single coordinates class, without any abstract inheritance, that was storing the data of coordinates in cartesian coordinates, but was able to read and write the coordinates converted to any other coordinates system. So, it behaves like one system or another at the same time, by storing the coordinates data only one time, no multiple times.
The meca numbers have been maybe the most creative part of this library. They have had some improvements in their design and in their implementation, but they've remained relatively constant in their idea over time, and to they haven't changed a big amount over the history. Their central idea has, instead, been fixed.
Besides that, they've been a very hard implementation. The most important class has been angle_number, at the present called simply angle. This class has not presented any problem in their implementation, it has been easy besides his big utility, but the other classes doesn't have that history. The safe_number class has been one of the hardest, as the class lab_number. Both of those classes have been hard to implement with unit classes, because they were requiring, for that purpose, to convert the class scalar_unit to a template class, instead of been a normal class. That extra amount of complexity was meaning that safe_number and lab_number were not really useful classes. Then, safe_number has been removed from the library, and lab_number has been converted to a template class, that instead of, as previously, being composed inside a scalar_unit object, now holds scalar_units as value and as error_value, and then it works with an easy to use API.
The unit classes have been hard to create, and have been a good challenge. Their first implementation was functionally perfect, they work good to allow to work with units instead of with numbers, as was their purpose. The implementation was with an abstract scalar_unit class and their derived unit classes, like mass, length and force, that were fixed in dimensions, allowing only to change their prefix. Besides that, there was the auto_unit class to allow to have a unit with any dimension needed. Apart from the scalar_units, there was the vector_unit class, and their derived vectorial unit classes, like force and velocity. In order to allow to have a vector_unit with any dimension, the class auto_vector was available. Needed for the implementation, there were the scalar_unit_crtp<> and vector_unit_crtp<> classes.
The problem with that first version of the units library was his complexity. The classes auto_unit and auto_vector were adding too much complexity. Also, the implementation wasn't as simple enough in order to allow for a compilation enoughly simple and close to the use of float as possible. That was very important, because to have an implementation that was producing machine code close to the code produced when working with float was meaning that the implementation was as perfect as possible, because it's not possible to have a unit class more simple than the central primitive type it uses.
Then, the second version of the units library was created, which was simplifying the complexities of the first, making a simpler implementation that was allowing a simpler compilation. For that purpose, scalar_unit was changed to be a normal class, instead of an abstract class, and vector_unit has losed his multiple inheritance with coordinates classes. Additional to that, vector_unit has been divided in vector_unit_1d, vector_unit_2d, vector_unit_3d and vector_unit_nd classes. This division was allowing to have a better protection against an incorrect use of dimensions, and was saving RAM because of storing less variables for the cases were was not needed to store more variables related to dimensions, which were msci::angle classes.