Boost LA defines many operator| overloads that return various view proxy references to vector and matrix objects. For example, to work with the transposed view of a matrix m, you could simply use m|transpose.
The convenience of operator overloading for this purpose, and the reasons for selecting operator| in particular (and its drawbacks) are explained below.
Boost LA implements view proxies very efficiently. The effect of using a view proxy is that it chains up an additional level of matrix_traits/vector_traits access functions.
While it is possible that the compiler might not inline this additional function call, even without using view proxies reliable inlining of simple access functions is already critical for the performance of Boost LA (for targeted control, all such functions invoke the BOOST_LA_INLINE_CRITICAL configuration macro.)
Assuming inlining works, view proxies should have negligible or no overhead because they do not create temporary objects. This makes it practical to use composition to get accumulative effects. For example:
//Store the 3D vector v transformed by the matrix m1 //into column 1 of m2, swapping its X and Y coordinates. m2|col<1>|YXZ = m1 * v;
Making a small change to the example above, we get:
m2|col<1> = m1 * v|YXZ;
This expression swaps the X and Y coordinates not of v, but of the result from transforming v by m1 (which of course is also a 3D vector.)
So the downside of operator| is that its precedence is lower than the precedence of most other operators and this often requires parentheses.
We could use regular function call composition instead of operator overloading, which would make our last example completely unambiguous:
col<1>(m2) = m1 * YXZ(v);
However additional levels of composition become uglier:
YXZ(col<1>(m2)) = m1 * v;
Another possibility would be to use operator/ instead, which has much better precedence for this purpose, but this choice has no semantic justification whatsoever.