Это не баг. Первым обрабатывается верхний вход, а нижний вторым.Сообщение от pop70
Угу. Почему-то
Вот это - баг.
Это не баг. Первым обрабатывается верхний вход, а нижний вторым.Угу. Почему-то
Вот это - баг.
O__O
Что значит "первым обрабатывается верхний вход"? Вы что вкладываете в понятие "обработка входа XOR"?
да как в javascript: foo && bar, если первое false то второе уже не проверяется
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Да вот нифига. У xor-a в любом случае нужно оба входа считать.
Это же, всёже, or, а не and.
Да и в нерабочем варианте видно, что 1 на вход xor-a не пришла по "железной связи".
Тут какой-то другой косяк.
И ведь в другом макросе работает и с нижним входом.
я про то что применяется некоторая последовательность,слева на право, сверху вниз
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Нет. Тут какая-то проблема с моментом инициализации константы, скорее всего. Похоже, она в том примере, почему-то, инициализируется позже нижнего входа xor-а, но до ЛЗ. Не понятно почему в других случаях такого нет. Как-то видимо связано с построением дерева вычислений и с остальной схемой. Хотя, константы, по идее, должны инициализироваться в первую очередь - раньше всего остального.
Интересно. Оно и в ПР так же будет, или это симулятор только дурит?
Последний раз редактировалось pop70; 03.08.2017 в 21:13.
Не имеет значения XOR или нет, я говорил об этом.
Снимок.PNG Снимок1.PNG Разницу видите? Функция одна и та же, а вычисление разное.
Последний раз редактировалось Василий Кашуба; 03.08.2017 в 22:17.
И? Результат вычисления разный что-ли получается?
То, что стек используется по-разному это "особенность реализации" (отсутствие оптимизации использования стека).
А если от порядка входов AND меняется результат, то это уже бага ОЛ.
Ваши права
Ответить с цитированием