[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]В случае разных типов я бы указал приведение к типу. Его тут есть?[/uquote]
Причём тут "приведение типа"?
Что такое a,b,c? Здесь форум для телепатов?
Предполагаю что это:
Соответствует вашему примеру? Да! Вы это имели в виду или что-то иное? Только телепат знает что имелось в виду. И как прикажете угадать нетелепатам?
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту.[/uquote]
Для этого есть
volatile. Если вам нужно именно это, то нужно описать:
int volatile a, b, c; (это опять к слову о том - зачем описывать что такое a,b,c)
И тогда будет работать именно так. Без volatile - как я описал выше.
Если человек имел виду такой алгоритм, но написал как вы привели (без volatile) -
код кривой, а написатель его - сам себе дурак. Как я уже говорил. И дело не в компиляторах/оптимизаторах, а в написателе сего недоразумения. Впрочем - у неумех всегда во всём инструмент виноват.
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955654#p3955654"]Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.[/uquote]Баги компиляторов есть, я же не отрицаю (и даже сам их находил и не один). Но в 99.99% случаев кривизна работы какого-то кода - заслуга не кривого компилятора, а прослойки между стулом и клавиатурой.
А "опции отключающие" - придумали главным образом -
для возможности отладки с привязкой к исходному коду. Так как - чем выше уровень оптимизации - тем труднее сопоставить исходный код, результирующей последовательности асм-команд.
Если какие-то неумехи используют эти опции всегда (так как не умеют писать код, корректно работающий с любым уровнем оптимизации), то это говорит только об их уровне компетенции.
А нормальный программист если видит, что при включении максимальной оптимизации, програмамма стала глючить, начинает искать ошибки
в своём коде. А не заметает проблему под ковёр, отключая оптимизацию. Второе - признак
быдлокодера, а не программиста.
Добавлено after 9 minutes 6 seconds:
[uquote="sergey.UA",url="/forum/viewtopic.php?p=3955712#p3955712"]Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT.
jcxz, что вы имели в виду ?[/uquote]
Переменная счётчика цикла (fahr) у вас типа float. float - это значение
с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.
А значит на 16-м шаге значение fahr будет: fahr = lower + step * 16 + delta * 16
delta будет зависеть от особенностей реализации операций FPU в данном конкретном компиляторе/МК, а также - от фазы Луны (delta может быть больше или меньше 0).
А значит в каких-то случаях у вас будет 16 шагов, а в каких-то - 15 шагов.
Добавлено after 7 minutes 16 seconds:
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955753#p3955753"]Использование float не делает из кода "быдло".[/uquote]Если float - в качестве счётчика цикла - делает.
[uquote="BlackKilkennyCat",url="/forum/viewtopic.php?p=3955753#p3955753"]Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы.[/uquote]А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего?

Вот это и называется быдлокод - скомпилили одним компилятором - 16 проходов, другим - 15. Конечно виноват компилятор и не быдлокодер!
