Re: [boost] QVM Review

Subject: Re: [boost] QVM Review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-17 15:05:32

On Thu, Dec 17, 2015 at 9:50 AM, Phil Endecott <
spam_from_boost_dev_at_[hidden]> wrote:

> Emil Dotchevski wrote:
>
>> 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);
>

Obviously it isn't possible for QVM to change 3rd-party type definitions to
define implicit conversions, but it does provide a conversion function that
you can call as noted in
http://zajo.github.io/boost-qvm/Interoperability.html:

xyz::g( make<xyz::matrix>(abc::f()) );

The make<> function is not needed if any QVM type is involved: the
qvm::mat<> type for example converts implicitly to any compatible matrix
type, and so do all the view proxies; if you did xyz::g( transp(abc::f()) )
there is no need to call make<>.

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

If your types define operators the compiler will always prefer them over
anything QVM defines, so if you want to define any super efficient
operation for any of the types you use, just define it and it'll work. QVM
can still help by filling-in the gaps: you define the critical stuff, it'll
provide everything else.

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

Yes, colors are a good use case for swizzling. I've been thinking that it
makes sense to add RGBA names for this. Anyway, if your point is that
swizzling isn't needed in C++ as much as in GLSL, that's fine, just don't
include qvm/sw.hpp. :)

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

No, not at all.

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

See the previous message I posted on this list about making X(v) equivalent
to (v,X), I'm interested to know if this alleviates your concerns.

Thanks,
Emil