Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-13 15:13:38

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_at_[hidden]> 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<float,3> float3?

> 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