Hi, here my quick review based on the documentation. I will not partake in the current discussion of the swizzling syntax.
We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost Not now, but at a later point surely.
* Conditions for acceptance This is not because the library is not relevant or useful, or because of bad design, but because it misses important functionality in the current state that would give it impact in the current ecosystem. "If I already have to use two competing point libraries, why should I additionally introduce qvm?" The scope must be broadened by including some advanced algorithms which make qvm useful in the ecosystem, also interoperability with already existing boost components must be established. Some of its functionality already exists in boost, which makes acceptance as a standalone library a bit odd. It could be worthwhile to merge qvm with another geometry related boost library to strengthen the links between the libraries.
- Your knowledge of the problem domain. I have got basic knowledge in robotics and graphic applications, some physical simulations
You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Usefulness
* Design The design makes sense. However for many use cases the current bindings are too complicated and for the problem of interoperability of point types, the issue of order has to be addressed, e.g. if one library takes
One has to see this library in the context of current program design in
robotics. Typically we have some robotic application, for example an arm
that has some software to move its joints in space.
On the other hand we have a physical simulation of the arm, the object
it carries, forces that are applied to it, and often a graphical
simulator showing the (simulated) position of the arm. These software
pieces are developed by different groups which need a definition of a
point or a matrix etc and somehow these parts have to be stitched
together in an application so that they work.
qvm has to be seen in this context as the 15th standard designed to
unify the 14 other standards that are out there( https://xkcd.com/927/
). I think it does a good job at it as it provides a reasonable
abstraction layer and a set of operations which then can be used without
taking the types of the arguments into account, so that points from the
one library can be taken and easily used together with the points of
another library.
points as ARGB while the other provides them as RGBA, assigning points
between the two libraries should automatically do the right thing and
not assigning the R part of the one point to the A part of the other.
Bindings should make this explicit as swizzling is always a source of
confusion and the library should make it as simple as possible to make
this automatic.
In many cases, points are some POD type in one of the many conventions
for which reinterpret_cast