Re: [boost] QVM Review

Subject: Re: [boost] QVM Review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2015-12-17 12:50:17

Emil Dotchevski wrote:
> On Wed, Dec 16, 2015 at 12:26 PM, Phil Endecott <
> spam_from_boost_dev_at_[hidden]> wrote:
>
>> Actually since first looking I've
>> found that it does have more functionality than I thought - for
>> example, I've only just found that it has functions to create
>> matrices representing rotations (but not any other affine
>> transformations)
>
> Not true, it can do translation and scaling as well. There is no shear
> support right now but that's easy to add if needed.
>
> The expression trans_m(v) reinterprets v as a translation matrix.
>
> Scaling is done by diag_m(v), which reinterprets v as a matrix whose
> diagonal is the elements of v with all other elements zero.

Ah, I've finally found those in the "Vector-to-matrix view proxies"
page.

>> and to compute the inverse of a matrix (but not
>> the determinant).
>
>
> Not true, there is the determinant() function

My apologies, I should have noticed that one.  I think I was
under the impression that the page was ordered alphabetically, or
something.

> the point of QVM isn't to add to the mix but to define an 
> environment where all of the existing types can be used 
> safely together.

Well let's look at that.  Say I have a couple of libraries
that each define their own matrix classes:

namespace abc {
   class matrix;
   matrix f();
};

namespace xyz :
   class matrix;
   void g(matrix m);
};

Ideally, I'd like to be able to write simply

   xyz::g( abc::f() );

and have the abc::matrix magically converted into an xyz::matrix.
How much does QVM help?  I can't write that "ideal" code, but
maybe this:

   abc::matrix m1 = abc::f();
   xyz::matrix m2;
   qvm::assign(m2,m1);
   xyz::g(m2);

I'm not really convinced that that is very useful.

What QVM does let you do is to, for example, multiply two abc::matrices.
But say libabc already had its own super-efficient matrix multiplication
algorithm, e.g. a multiply(a,b) function.  I don't think QVM has any 
way to
use that in its operator* implementation.

> The swizzling syntax must be terse or else it's useless. If you've written
> shader code you'll know utterly inadequate it is to require a syntax like
> swizzle<1,0,3,2>(vec) instead of (vec,YXWZ). At any rate, swizzling is
> defined in a separate header, don't include it if you don't want it.

Actually I have written quite a lot of OpenGL code.  I asked before for
examples of this and the only one I was given was converting colours
between RGBA and BGRA.  This is mainly just curiosity; I don't doubt that
you do write such code.

I am starting to wonder if what you're really trying to achieve is a
GLSL-like DSEL, i.e. specifically to write C++ that looks like shader
code.

Quoting from another message:

> Also, let's say you want to access the X coordinate of a vector, (vec,X) is
> more readable than X(vec).

I honestly find that point of view totally bizarre.  The function call syntax
is the most basic thing we have in "C family" languages, it's practically
the first thing that any programmer learns.  Yet you prefer to write (vec,X)
which is completely opaque until you discover that operator, has been
overloaded.

If your motivation is to do whatever is necessary in order to put the
name of the operation after the argument, just wait for "unified call
syntax" or "extension methods" (n4165, n4174).

Regards,  Phil.