您如何解决模板运算符之间的歧义？

Question

I've looked far and wide and everyone seems to have a slightly different issue than me.

For simplicity say I have a template struct Complex<X> and I want it to have overloads for real values and at least other Complex. As a rule, operations between double or Complex<double> and Complex<float> (on either side) should return Complex<double> . I'm currently using deduction guides that work quite well for this, but other options are std::common_type_t<X,Y> , decltype(std::declval<X>()+std::declval<Y>()) , etc.

(1) `auto operator+(X const&)`
(2) `friend auto operator+(X const&, Complex<X> const&)`
(2) `template<class Y> auto operator+(Y const&)`
(3) `template<class Y> auto operator+(Complex<Y> const&)`
(4) `template<class Y> friend auto operator+(Y const&, Complex<X> const&)`

Here's the problem. If I write (1-2), then Complex<float> sees doubles as floats. If I make that (2-3), then apparently adding Complex<double> is ambiguous between (2,3,4). Non-template operators wouldn't be ambiguous, but please assume there are too many template arguments to name.

Next I thought that the CV/references were to blame, but making (1-2) operators of X changed nothing. This appears to be opposite the behavior of auto x which won't be a reference.

I tried adding assertions like static_assert(std::is_arithmetic_v<Y>) to (1-2) but they don't participate.

Answer 1

After trying static assertions that didn't help from the function body, I thought before I move on I should try enabling/disabling functions another way. I remember this approach not working correctly in the past, so I didn't try it until much too late.

template<class Y>
auto operator+(Complex<X> const& x, Complex<Y> const& y)
-> std::enable_if<std::is_arithmetic_v<Y>,
    Complex<decltype(std::declval<X>(), std::declval<Y>())>> {/*...*/}

template<class Y>
auto operator+(Complex<X> const& x, Y const& y)
-> std::enable_if<std::is_arithmetic_v<Y>,
    Complex<decltype(std::declval<X>(), std::declval<Y>())>> {/*...*/}

template<class Y>
friend auto operator+(Y const& y, Complex<X> const& x)
-> std::enable_if<std::is_arithmetic_v<Y>,
    Complex<decltype(y, std::declval<X>())>> {/*...*/}

This isn't the code I'm using, I've paraphrased everything. Please let me know if I made a mistake somewhere.

This table shows the sum type of the row and column correctly. If either field type has double precision then so does the result; the same goes if either type is complex.

    add          f           d      Complex<f>  Complex<d>
     f           f           d      Complex<f>  Complex<d>
     d           d           d      Complex<d>  Complex<d>
Complex<f>  Complex<f>  Complex<d>  Complex<f>  Complex<d>
Complex<d>  Complex<d>  Complex<d>  Complex<d>  Complex<d>

As an aside, if you define assignment operators like operator+= , then Complex<X> only goes on the left (no friend functions) and only returns Complex<X>& (type is fixed.) It should probably accept the same types as operator+ or use operator+ directly, so it only rounds at assignment/conversion.

template<class Y>
auto operator+=(Y const& y)
-> std::enable_if<std::is_arithmetic_v<Y>,
    Complex>& { /*...*/ }

Answer 2

I assume that you don't want to use std::complex for some reason. Now you have to decide the type of complex<float>+double ; is it going to loose some data?

1. If the result is complex<float> , then precision bits of double are lost and large values are clamped to INF .
2. If the result is double , then the imaginary part is gone.

Thus, the best of both worlds would be complex<double> . A closer looks reveals that your problem boils down to conversion/promotion to/from numeric types. You are going to need conversion constructors:

#include <concept>
template<std::floating_point numeric>
class complex{
public:
    constexpr complex(numeric const r=0,numeric const i=0);

    template<std::floating_point othern>
        requires std::constructible_from<numeric,othern>
        explicit(!std::convertible_to<othern, numeric>)
    constexpr complex(complex<othern> const&);
    //...

Now you can simply define:

    //continue class declaration:
    friend auto const& operator(complex rgt, complex const& lft)
        {return rgt+=lft;};
    complex const& operator+=(complex const&);
    //...

This approach hits two birds with one stone. For completness I would define one conversion operator too:

    //still inside class complex:
    explicit constexper operator numeric() const
        {return this->real();};
    //...

The explicit specifiers - in declaration of conversion constructors and operator - conducts correct deduction and required implicit. conversions