On Thu, Dec 17, 2015 at 9:50 AM, Phil Endecott < spam_from_boost_dev@chezphil.org> 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( makexyz::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