Rajaditya, thank you for the detailed review! Below I'll respond to a few points you made. On Sat, Dec 12, 2015 at 10:15 PM, Rajaditya Mukherjee < rajaditya.mukherjee@gmail.com> wrote:
*Conditionally Accepted into Boost* * * Conditions for acceptance* 1. The author should provide out of box versions of 2,3,4 dimensions vector matrix quaternion classes which can be readily imported by the user and used (without messing around with traits and such).
There are such class templates: quat<>, vec<> and mat<>. Or do you mean
that you want to have specific typedefs like typedef vec
3. Compatibility with GLSL pipeline (like glm currently provides ) will be a big plus since it is the target demographic for this library.
I agree, there should be OpenGL and DirectX and other popular API bindings included in QVM.
The test battery is pretty comprehensive. However some of them require modifications to run in the new system because they use boost::test_tools::check_is_close which is depreciated in the current version as per this link ( http://lists.boost.org/boost-users/2015/09/85042.php). I would request Emil to update them as per the link so it runs without modification on newer boost systems.
Thank you for this note, will do.
*- Did you attempt to use the library? If so:* ** Which compiler(s)* MSVC 2013 ** What was the experience? Any problems?* There are certain trivial issues I encountered with MSVC. Emil resolved them pretty fast in the mailing list but right now, this library is not very MSVC friendly.
Could you clarify, what do you mean by it is not MSVC-friendly? I've been using QVM with MSVC for years without a problem except for the MSVC parsing bug you stumbled upon with (v,A<i>) (I've added that in the known issues page: http://zajo.github.io/boost-qvm/known_quirks_and_issues.html).
For instance the library absolutely needs the default constructor for certain operations (normalized in my case couldn't run without a default constructor, I will be happy to discuss the exact testing scenario that brought this comment as a followup).
Yes, I'm interested to understand what brought this comment, though I am not sure that there is a solution. The problem is that QVM can't invoke constructors (other than the default constructor) for user-defined types, because different types could have different constructors (believe me, I've seen game programmers define some crazy matrix/vector constructors). Because functions like normalized() operate on user-defined types, they use the default constructor to make a local object before returning it by value. It is possible to change normalized() to always return qvm::vec<>, which converts implicitly to any compatible vector type, but that would introduce a temp when assigning to a user-defined vector type. That seems like a bad idea. Thanks once again! Emil