Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-31 00:20:26
On Wed, Dec 30, 2015 at 11:39 AM, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]
> 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 &&
template <class A,class B>
operator*( A const & a, B const & b );
The above clearly defines that the return type is deduced by the deduce_m2
Furthermore AFAIU two-argument deduce_xx are only used in operations taking
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk