On Wed, Dec 30, 2015 at 11:39 AM, Adam Wulkiewicz wrote: Emil, do you think that the deduce_xx traits are something that is crucial
for the library? Or could it be e.g. hidden in the details? Without this machinery it wouldn't be possible to customize the return type
for binary operations invoked with different user-defined types.
Specializing this template also helps avoid temporaries. I'm asking because in general in QVM return types are hidden from the user
and only if the user wants to do something special he must e.g. overload an
operator or a function. Why not rely on this mechanism also in this case? I'm not sure what you mean by "hidden from the user". For example, matrix
multiplication is documented like this:
//Only enabled if:
// is_m<A>::value && is_m<B>::value &&
// m_traits<A>::cols==m_traits<B>::rows
template operands of the same kind and returning a result of the same kind as the
operands, where "kind" means "type adapted to the same concept", e.g.
matrix from two matrices, vector from two vectors, etc. So while the
coverage is quite good operations taking various kinds of arguments like
e.g. a vector and a scalar generating a matrix are not covered. In such
cases the library can return any type, right? deduce_m is used by unary operations that need to deduce the return matrix
type from the type passed as the argument.
deduce_m2 is used by binary operations that need to deduce the return
matrix type from the two types passed as arguments.
This is the complete list of return type deduction templates, by analogy:
- for quaternions: deduce_q/q2;
- for vectors: deduce_v/v2;
- for matrices: deduce_m/m2;
- for scalars: deduce_s. So I'm wondering, would it be a good idea to simply pick some good default
and simply rely on overloading if something fancy was needed?
The default could be the same type for two operands of the same type, and
something unspecified in other cases, so the same as it is now. There is a good default type, just don't specialize deduce_m2. See
http://zajo.github.io/boost-qvm/deduce_m2.html.
Emil