Re: [boost] Formal review for QVM

On Sun, Dec 13, 2015 at 3:16 PM, Rajaditya Mukherjee < rajaditya.mukherjee@gmail.com> wrote:

​I will try to clarify the

...

...

*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 float3 ​?

​ I will confess that I had missed that quat<> vec<> and mat<> were already present. I was hinting at that but the convinient typedefs would definitive be a plus. Libraries like Eigen and GLM also do it nad it would definitely enhance the readibility and "out-of-box" usability of the library. ​

To clarify, these types ( http://zajo.github.io/boost-qvm/quaternion_vector_and_matrix_types_reference...) aren't provided just for convenience, they serve as the default return types for binary operations that are invoked with arguments of different static types. For example, if you multiply a user-defined type mat33 by a user-defined type matrix33, what type should the result be? In QVM, by default you're going to get a suitable instance of the qvm::mat<> template, which can be assigned to any compatible user-defined matrix type, including the types used as arguments. You can specialize the deduce_m2 template to specify a different type depending of the argument types.

...

...

** 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).

​I thought that bug about the need for default consturctor was a MSVC thing.

No, it is not. I don't think that matrix or vector types without a default constructor exist in the wild, perhaps I'm wrong. So yes, at the very least I need to explicitly state the requirement for an accessible default constructor.

I have explained it below and if it is something which I am not understadning correctly, please point out to me. So essentially I wrote this small piece of code (same as one before) ​ #include #include <iostream>

class float4 { public: float4(float a, float b, float c, float d) { container[0] = a; container[1] = b; container[2] = c; container[3] = d; } float container[4]; };

namespace boost { namespace qvm { template<> struct v_traits<float4> { static int const dim = 3; typedef float scalar_type;

template <int I> static inline scalar_type &w(float4 & v) { return v.container[I]; } template <int I> static inline scalar_type r(float4 const & v) { return v.container[I]; }

static inline scalar_type &iw(int i, float4 &v) { return v.container[i]; } static inline scalar_type ir(int i, float4 const & v) { return v.container[i]; } }; } }

using namespace boost::qvm;

int main() { float4 vec(11.0, 0.0, 5.0, -6.0); 1----std::cout << mag(vec); 2----std::cout << mag(normalized(vec)); }

​So the issue is that line 1 works without ​the presence of default constructor but line 2 needs the same (more specifically the normalized in place keyword needs it). I weas just wondering if there is a generic way to enforce this behavior.

Yeah, I'd just add a default constructor to your float4 type. I believe you'll need it anyway outside of a toy example like this. Thanks! Emil