Adding non-member functions to make interface easier to use.

Issue #7 resolved
edanor repo owner created an issue

In its current state, interface is able to handle most of operations using member functions with invocation subject used as implicit operand. The code gets unreadable and it would be good to have a "function-like interface".

There is a major problem with making this interface auto-generate: limitation of type resolution in C++ templates. When declaring such operations that use both scalar and vector operands, it is not possible for the compiler to decide which template resolution to use. Consider this example:

template<typename VEC_TYPE>
inline VEC_TYPE addv (VEC_TYPE const & src1, VEC_TYPE const & src2) {
    return src1.add(src2);
}

template<typename VEC_TYPE, typename SCALAR_TYPE>
inline VEC_TYPE adds (SCALAR_TYPE src1, VEC_TYPE const & src2) {
    return src2.add(src1);
}

template<typename VEC_TYPE, typename SCALAR_TYPE>
inline VEC_TYPE adds (VEC_TYPE const & src1, SCALAR_TYPE src2) {
    return src1.add(src2);
}

First definition uses vector types only and does not pose any problems.

Second and third definitions use SCALAR_TYPE on varying position. Because it is not possible to call the member function on a scalar, it is necessary to make a distinction between scalar position in function argument list. Unfortunately compilers are not able to parse this information and make more elaborate guess on which invocation makes sense.

One solution would be to make scalar types explicit:

template<typename VEC_TYPE>
inline VEC_TYPE adds (float src1, VEC_TYPE const & src2) {
    return src2.add(src1);
}

template<typename VEC_TYPE>
inline VEC_TYPE adds (VEC_TYPE const & src1, float src2) {
    return src1.add(src2);
}

This is a bad idea because it would require writing all possible combinations of scalar types for all functions exposed this way.

Restricting these calls only to vector-vector operations seems a good trade-off at this time, but is not the best from the usability perspective.

[Note to users] Please add comments if you are interested in this feature and/or if you have any hints on this idea.

Comments (1)

  1. edanor reporter

    File: /umesimd/SIMDInterfaceFunctions.h now contains definitions of non-member functions that propagate calls to the interface. This interface can be accessed using UME::SIMD::FUNCTIONS:: namespace.

  2. Log in to comment