Re[3]: operator int - C/C++. Прикладные вопросы

Здравствуйте, B0FEE664, Вы писали:

BFE>Для выражения x = v + u + z можно подобрать такие v + u + z, что в зависимости от порядка выполнения операций промежуточный результат может как оставаться в пределах или же выходить за пределы. В стандарте есть разъяснения по этому поводу.
BFE>

BFE>5 [Note 4 : The implementation can regroup operators according to the usual mathematical rules only where the
BFE>operators really are associative or commutative.41 For example, in the following fragment-*

BFE>Вывод: порядок зависит от архитектуры.

Я все же склонен рассматривать это как особый случай и не торопился бы обобщать. В общем же случае порядок выполнения операций зависит и от приоритетов, и от ассоциативностей. Например, в выражении a — b + c компилер сначала выполнит вычитание и только потом сложение, но ни как не наоборот, хотя приоритеты у сложения и вычитания одинаковы. И это только потому, что обе эти операция являются левоассоциативными. То же самое с умножением и делением.

Здравствуйте, rg45, Вы писали:

R>Горький опыт говорит, что, чем больше наопределяешь операторов, тем с большей вероятностью получишь амбигус и тем труднее его будет разрулить.

Я таки думаю, что если граамотно всё сделать, то будет работать

А так — работает, без всяких варнингов

#include <iostream>

struct MyInt {
    int value{};

    operator int() const {return value;}
};

template < typename T, std::enable_if_t< std::is_integral_v<T>, int> = 0 >
MyInt operator + (const MyInt& a, T b) { return {a.value + int(b)}; }

int main()
{
    std::cout << MyInt{42} + sizeof(MyInt) << std::endl;
}

Здравствуйте, Marty, Вы писали:

R>>Горький опыт говорит, что, чем больше наопределяешь операторов, тем с большей вероятностью получишь амбигус и тем труднее его будет разрулить.

M>Я таки думаю, что если граамотно всё сделать, то будет работать

Ну это да, с прямыми руками можно сделать многое. Но вот с этим оператором преобразования ты зря затеял. Если есть другие варианты, то лучше обойтись без этого оператора.

Здравствуйте, Marty, Вы писали:

M>А так — работает, без всяких варнингов
M>MyInt operator + (const MyInt& a, T b) { return {a.value + int(b)}; }

без варнингов, но не правильно

#include <iostream>

struct MyInt {
    int value{};

    operator int() const {return value;}
};

template < typename T, std::enable_if_t< std::is_integral_v<T>, int> = 0 >
MyInt operator + (const MyInt& a, T b) { return {a.value + int(b)}; }

int main()
{
    std::uint64_t sz = 5'000'000'000;
    std::cout << MyInt{42} + sz << std::endl;
    std::cout << 42 + sz << std::endl;
}

705032746 5000000042

Кстати, тоже самое для

public: // to integral convertion

    template < typename T, std::enable_if_t< std::is_integral_v<T>, int> = 0 >
    operator T() const
    {
        if constexpr (std::is_signed_v<T>)
        {
            std::int64_t t = 0;
            moduleToIntegralConvertionHelper(t);
            return T(t);
        }
        else
        {
            std::uint64_t t = 0;
            moduleToIntegralConvertionHelper(t);
            return T(t);
        }
    }

возвращаемый результат moduleToIntegralConvertionHelper(t) не проверяется.

Здравствуйте, B0FEE664, Вы писали:

BFE>без варнингов, но не правильно

BFE>BFE>705032746 BFE>5000000042

Чой-то неправильно? Результат 42+5000000000=0x12A05F22A — 9 hex цифр, int, очевидно, 4х-байтный, усекается до 0x2A05F22A = 705032746

BFE>Кстати, тоже самое для
BFE>

BFE>public: // to integral convertion
BFE>

BFE>возвращаемый результат moduleToIntegralConvertionHelper(t) не проверяется.

И не должен, так и задумано. Разве компилятор тебе что-то говорит, когда у тебя в рантайме при работе с интегральными типами происходят переполнения/усечения? Так и тут я сделал.

Для того, чтобы сконвертировать в интегральный тип с проверкой, у меня есть метод

template < typename T, std::enable_if_t< std::is_integral_v<T>, int> = 0 >
    T checkedConvert(bool *pValid=0) const
    {
        if (pValid)
            *pValid = true;

        if constexpr (std::is_signed_v<T>)
        {
            std::int64_t t = 0;
            moduleToIntegralConvertionHelper(t);
            if (pValid)
            {
                if (t > std::int64_t(std::numeric_limits<T>::max()))
                   *pValid = false;
            }
            return T(t);
        }
        else
        {
            std::uint64_t t = 0;
            moduleToIntegralConvertionHelper(t);
            if (pValid)
            {
                if (t > std::uint64_t(std::numeric_limits<T>::max()))
                   *pValid = false;
                else if (t < std::uint64_t(std::numeric_limits<T>::min()))
                   *pValid = false;
            }
            return T(t);
        }
    
    }

Тут я, правда, слегка косякнул, и забыл проверить результат moduleToIntegralConvertionHelper, надо пофиксить

Здравствуйте, Marty, Вы писали:

BFE>>Кстати, тоже самое для
BFE>>

BFE>>public: // to integral convertion
BFE>>

BFE>>возвращаемый результат moduleToIntegralConvertionHelper(t) не проверяется.

M>И не должен, так и задумано.
Непонятно зачем.

M>Разве компилятор тебе что-то говорит, когда у тебя в рантайме при работе с интегральными типами происходят переполнения/усечения?
Вообще-то, если тип знаковый, то это UB

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.

А если тип беззнаковый, то всё считается по модулю.

M>Так и тут я сделал.
С какой целью? В каком сценарии переполненный int не приводит к ошибке?

	От:	rg45
	Дата:	26.05.25 20:57
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	26.05.25 21:12
Оценка:

	От:	rg45
	Дата:	27.05.25 06:22
	Оценка:

	От:	B0FEE664
	Дата:	27.05.25 13:48
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	27.05.25 14:39
Оценка: