$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [qvm] Terseness of syntax etc.
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2015-12-09 09:23:34
Emil Dotchevski wrote:
> I agree that transp is perhaps too short. The q_, v_ and m_traits though
> shouldn't be a problem since throughout the entire library q, v and m mean
> the same thing.
Throughout the entire *library*, yes; while you're writing your library
I'm sure you don't get confused about what q, v and m stand for. But when
they appear in my application, which pulls in maybe a dozen libraries,
these short names are incomprehensible.
Imagine the scenario where someone picks up some code written by someone
else and needs to understand it: they really need to be able to read
it without referring to the documentation for an obscure library first.
> The ir/iw accessors are for dynamic indexing and are generally optional.
> You use r and w for read and write access and in that case access to x, y
> and z can be implemented as specializations.
Yes I'm aware of the template-index-parameter versions. But I was asking
about those that take run-time index parameters. For example, consider
a matrix-multiplication function; most likely that will use loops and
invoke the ir/iw accessors. Have you looked at whether compilers produce
respectable code in that case for structs with x,y,z elements?
>> I'm really not a fan of the old operator% and now operator, syntax.
>> To me, (v,XY) looks like you're forming a row-vector with two elements.
>> Is there a reason why these accessors can't be written with function
>> syntax, i.e. XY(v) ? Or, for matrices, something like element<4,2>(m)
>> rather than (m,A<4,2>) ?
>
> There is (m,A42) actually which seems preferable to element<4,2>(m).
No, (m,A42) is not preferable to element<4,2>(m):
- The (...,...) syntax doesn't look like a function invocation, it
looks if anything like you're trying to form a row-vector with two
elements.
- "A" presumably is short for "at", saving one letter of typing at
the expense of incomprehensibility.
- "42" says forty-two, not 4,2.
> There is no good solution for swizzling, unfortunately.
As an aside, I think it would be useful to present a motivation for the
"swizzling" operations. I.e. a simple "real" example of why you might
want to "swizzle".
Also, I find the word "swizzle" a bit odd. To me it means the same as
"munge" or "frobnicate" i.e. it's a nonsense-word that you use as a
placeholder. I think what you're really doing is often a permutation,
and could be named e.g. permuteZYX() - but there are other cases where
you're duplicating or removing elements that aren't strictly permutations.
Maybe there is some other mathematical term that encompasses that.
Regards, Phil.