Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Rajaditya Mukherjee (rajaditya.mukherjee_at_[hidden])
Date: 2015-12-13 18:16:54

​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<float,3> 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.   ​

> ​
>

>
> >
> > *- 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).
>
>
​I thought that bug about the need for default consturctor was a MSVC
thing. 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 <boost/qvm/all.hpp>
#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. In the usecases in your tests, most of them use the
default constructor so it doesn't manifest itself too much.  But I read
your comment about returning a qcm::vec<> type and I do understand the
problem you mentioned.

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>