Здравствуйте, T4r4sB, Вы писали:
M>>У Страуструпа в старом издании начала века в приложении B.6.2.6 о преобразовании плавающих в целые
TB>Ну если так, то что будет для отрицательных чисел?
Конечно. Такие выражения игогда назвают "function-style conversions" и они эквивалентны "cast expressions": (int)std::round(3.14f). Вот что сказано по этому поводу в стандарте (C++17):
8.2.3 Explicit type conversion (functional notation)
2 If the initializer is a parenthesized single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (8.4)...
И вот еще цитата из 8.4:
8.4 Explicit type conversion (cast notation)
2 An explicit type conversion can be expressed using functional notation (8.2.3), a type conversion operator (dynamic_cast, static_cast, reinterpret_cast, const_cast), or the cast notation.
TB>>Ну если так, то что будет для отрицательных чисел?
M>Будет отброшена дробная часть, не?
Тут тебе придется с ним согласиться — твой вариант для отрицательных чисел будет работать не так как это ожидается от арифметического округления. Например, если мы захотм округлить -2.1, то получим: -2.1 -> -1.6 -> -1. Чтобы работало как надо, нужно слегка допилить:
R>Тут тебе придется с ним согласиться — твой вариант для отрицательных чисел будет работать не так как это ожидается от арифметического округления. Например, если мы захотм округлить -2.1, то получим: -2.1 -> -1.6 -> -1. Чтобы работало как надо, нужно слегка допилить:
R>
R>int i = (int)(d < 0 ? d - 0.5 : d + 0.5);
R>
Кто-то моё сообщение не дочитал
>для отрицательных надо отнять, если хочешь округление к большему по модулю
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, T4r4sB, Вы писали:
M>>>У Страуструпа в старом издании начала века в приложении B.6.2.6 о преобразовании плавающих в целые
TB>>Ну если так, то что будет для отрицательных чисел?
M>Будет отброшена дробная часть, не?
Ты сначала прибавил 0.5, потом кастанул к инту, что произошло?
Подсказка: проделай это с числом -3.14
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>>>Ну если так, то что будет для отрицательных чисел?
M>>Будет отброшена дробная часть, не?
TB>Ты сначала прибавил 0.5, потом кастанул к инту, что произошло? TB>Подсказка: проделай это с числом -3.14
Тоже не любишь до конца дочитывать?
>для отрицательных надо отнять, если хочешь округление к большему по модулю
Здравствуйте, T4r4sB, Вы писали:
>>>для отрицательных надо отнять, если хочешь округление к большему по модулю
TB>Круто, теперь у тебя есть функция с хитрым ветвлением внутри.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, T4r4sB, Вы писали:
>>>>для отрицательных надо отнять, если хочешь округление к большему по модулю
TB>>Круто, теперь у тебя есть функция с хитрым ветвлением внутри.
M>Чего тут хитрого?
Может, надёжнее сделать ветвление после округления?
f += 0.5f;
int i = int(f);
if (i>f) --i;
такой код правильно работает независимо от того, куда округляет каст
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
TB>такой код правильно работает независимо от того, куда округляет каст
Каст не округляет, а отбрасывает дробную часть. Если бы это было не так, или на разных платформах по разному, то это была бы глобальная жопа
ЗЫ Мой код (что-то типа inproc COM) работает под Win32 x86/64, Linux x86/64/Arm, и за него я вполне спокоен. Если что-то писать для embedded, то там могут быть нюансы, но там всё надо перепроверять в любом случае. Сейчас, кстати, под STM32 говнокодю
TB>>такой код правильно работает независимо от того, куда округляет каст
R>Ну где ж правильно-то? 2.9 должно округлиться до 3,
Да R>у тебя получается 2.
Неправда R>-2.1 должно округлиться до -2,
Да R>у тебя получается -3.
Неправда
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
R>>Ну где ж правильно-то? 2.9 должно округлиться до 3, TB>Да R>>у тебя получается 2. TB>Неправда R>>-2.1 должно округлиться до -2, TB>Да R>>у тебя получается -3. TB>Неправда
Да, все правильно, это я прогнал
Только чем это лучще? Вместо одного выражения: локальная переменная, условный оператор, модификация входного парамертра, дополнительное преобразование целого значения назад в число с плавающей точкой. В чем ты видишь выигрыш? Если это только ради того, чтоб подстраховаться на случай, если каст вдруг отработает не в ту сторону, то напрасно — как должен отработать каст прописано в стандарте языка.
