Заметил, что при приведении типа с плав. точкой (float) к целочисленному значению, дробная часть просто выкидывается, или производится округление к нулю: было 4.8, стало -> 4.
А надо бы юзать округление до ближайшего целого -> 5.

Пришлось подключить хидер rt_fp.h и пользоваться тамошней функцией UINT _ffixu_r(float).

Может быть, режим округления можно изменить каким-то другим, более правильным путём, не прибегая к вызову функций внешней библиотеки?

И почему такой грубый способ округления юзается по умолчанию? Разве это правильно - 4.8 округлять до 4?

Приведение типа переменной и округление чисел, вообще говоря не очень связанные между собой операции. Самый простой способ общепринятого округления чисел при преобразовании из float в int это прибавление к результату 0.5f непосредственно перед таким преобразованием.

Только числа бывают и отрицательными.

ИМХО, лучше вариант (int)floor(x + 0.5)

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

да, один клерк в банке наокруглял десятые доли цента за пять лет что-то на 20000 баксов.
И судить было вроде не за что, раньше машина их просто отбрасывала, а он заставил переводить на свой счет.

это такое соглашение если в выражении языка C нет вещественных то арифметика целочисленная
1/3 дает в результате 0, а если есть вещественное, то каждое целое переводится в вещественное 1/3. дает около одной трети :-)

Вот, спасибо, теперь буду знать
Хотя и смахивает это на некий костыль...


А вот здесь не понял, floor при округлении отрицательного числа (-4.8 + 0.5 = -4.3) даст результат -5?

Судя по всему да. ссылка
А я использую вот такие макросы
До такого не додумался

demiurg_spb
По идее да - floor округляет до целого, не превышающего начальное значение.
Если округлить -4.8 до -4, то -4 будет больше -4.8.
Значит, правильно будет -5

В принципе, чтобы юзать floor, надо подключить math.h
А чтобы юзать _ffixu_r, которая округлит число безо всяких заморочек, надо подключить rt_fp.h.
Не знаю, есть ли между ними какая-то разница

Имхо - самое простое - юзать предложенные вами макросы

Это не страшно.
А это уже нестандартно (видимо от keil примочки).
Это как сказать... У меня два макроса, а ведь можно обойтись одним. Вопрос что оптимальнее. Нужно экспериментировать.

В описании языка C четко сказано, что при приведении типа от вещественного к целочисленному дробная часть просто отсекается.

Я в курсе.
Имхо - очередная бяка стандарта
Почему то, в тех редких случаях, когда приходится юзать плавучку, ни разу не приходила в голову мысль портить вычисления использованием столь грубого округления.
Всегда приходится обходить "чётко оговоренный" стандарт

sonycman Операция отбрасывания дробной части лёгкая для процессора(наличие fpu роли не играет), в отличии от полноценного округления. Округление нужно далеко не всегда, поэтому можно избежать использования лишних операций. Так наверное во всех вменяемых языках устроено...

Ммм.. а например при целочисленном делении ( a / b, a >> x) вам никогда не приходило в голову, что значения напрасно портяться? (хотя могут быть относительно легко "округлены").

Не понял, в каком месте при делении "портятся значения"? Нужен остаток - никто не мешает его сохранить и использовать в вычислениях дальше.

А вот при отбрасывании дробной части числа 4.99 мы получаем чувствительную ошибку.
Я не затем проводил рассчёт в плавучке, чтобы затем при банальной передаче параметров всё угробить

предлагаю такой вариант:

long a=5.6;
//перед преобразованием умножать на 10, чтоб был остаток от деления в дальнейшем
a=a*10;
//теперь а=56
a=((int)(a+a%10))/10;
//поясню (int) (56+6) и деленое на 10 будет 6, что и необходимо

для отрицательного числа тоже пойдет


ЗЫ при проверке в досовском Borland: задавал а=5.1 далее умножал на 10 и получал а=50.999. кто может объяснить в чем дело?

Ну, дальше можно уже не читать.


Умножение + 2 деления + сложение = хороший пример того, как делать не надо.

Точность представления чисел конечная. Чего вы хотите?
Для float:
старший бит - знак,
8 бит - порядок со смещением 127,
23 бита - мантисса.

2^23= 8388608. Итог: имеем лишь ~7 десятичных значащих разрядов...

погуглите на тему: формат IEEE754

Чем плох вариант без подключения внешних библиотек? Единственным пожалуй минусом является время, что думаю не критично для ситуации. Ну а вторымб что он не пойдет, сейчас исправим

Вот работающий на 100% (сам проверял) листинг программки, выдающий требуемый результат:

Он бесконечно хуже такого макроса:

А уж это (выделено):

- вообще ни в какие ворота.

А то, что он "работает" - так это, извините, не аргумент.

не люблю разводить темы насчет демогогии выбора. каждый выбирает то, что хочет.
ЗЫ автору предложено 2 способа, думаю сам выберет, что подходит.

Sneg_87, такие "конструкции" в реальных проектах никто использовать не будет.
И никто Вам даже не будет объяснять почему! Это очевидно.


P.S. дизассемблер, кстати, клёвая штука. Предлагаю им воспользоваться