Emil Dotchevski wrote:
On Wed, Dec 16, 2015 at 12:26 PM, Phil Endecott < spam_from_boost_dev@chezphil.org> 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.