Проблема с условием, m = m+I|P == I ? m : 0; Опции

[ave!]

Приоритет операций C++ - это я себе в тему на заметку.

Эта конструкция скомпилится в большее число команд, чем простое, читаемое и аналогичное по результату: if (!(m + I) && P != I) m = 0;
И в других местах - аналогично.
Поэтому единственная цель такого поделия - сделать вычурный код.

jcxz, может вы поможете разобраться с остальными местами по списку.

[jcxz]

jcxz, может вы поможете разобраться с остальными местами по списку.

Мне кажется первая строчка к си не относится. Или там ошибка. Вы там где-то имя функции не забыли? Иначе компилятор должен был ругнуться.
В чём там разбираться? Компилируется? Работает? Тогда зачем разбираться?
А если не работает - отлаживать? нет уж, увольте

[Непомнящий Евген...]

Приоритет операций известен. Да, оно сложнее, чем a+b, но ничего неоднозначного и тем более неочевидного в нем нет. В a*x+b тоже будем скобки расставлять?

это конечно вкусовщина, но я бы расставил для всего кроме арифметических операторов. Наверное у меня такого кода очень мало и мне лень учить приоритеты, а также задумываться - разные ли они в си, питоне, яваскрипте и т.п.

[ave!]

Мне кажется первая строчка к си не относится. Или там ошибка. Вы там где-то имя функции не забыли? Иначе компилятор должен был ругнуться.

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

Стиль написания самой функции поиска следующего хода для меня не понятна:

short D(q,l,e,E,z,n)
short q,l,e;
unsigned char E,z,n;
{
//...
}

Я подозреваю, что это тоже самое что:

short D(short q, short l, short e, unsigned char E, unsigned char z, unsigned char n) {
//...
}

Под AVR компилятор пропустил и первую запись, а вот под STM не прошло.

[jcxz]

Стиль написания самой функции поиска следующего хода для меня не понятна:
short D(q,l,e,E,z,n)

Возможно там макросами что-то переопределено.

(1) while (d++<n||d<3||z&K==I&&(N<T&d<98||(K=X,L=Y&~M,d=3)))

Но такое не должно компилиться. имхо. выделенное.

[Сергей Борщ]

Возможно там макросами что-то переопределено.

Это K&R style, поддерживается компиляторами для совместимости с самыми старыми исходниками (созданными еще до принятия Стандарта языка), сейчас практически не применяется и это правильно.

Но такое не должно компилиться. имхо. выделенное.

Почему? Оператор "запятая" никто не отменял.

Я подозреваю, что это тоже самое что:

Да, именно так.

[jcxz]

Это K&R style, сейчас практически не применяется и это правильно.

и ну его... в сад.

[yes]

ну дык (по описанию micro-Max) задача стояла минимум символов в коде, поэтому такой код
была такая специальная олимпиада по С программированию , помню печать кода программы в стдаут, например, но чтобы шахматы - это охренеть

[jcxz]

ну дык (по описанию micro-Max) задача стояла минимум символов в коде, поэтому такой код
была такая специальная олимпиада по С программированию , помню печать кода программы в стдаут, например, но чтобы шахматы - это охренеть

А я вот помню что когда-то умудрялись написать программу в ASCII-символах. Т.е. - файл программы состоял только из байтов печатаемого диапазона ASCII-кодов: 33...126.
Отсылаешь такую прогу как обычный текст, сохраняешь в файл, переименовываешь его в расширение .com и запускаешь
Без всякого base- или uue-кодирования. А если применительно к МК, то никакого .hex тогда не надо, .bin вполне текстовый был бы.

[Arlleex]

Ибо: вместо t += p<5 простой программист использует if, а более продвинутый заменит на что-то типа: t -= (int)(p - 5) >> 31;

А еще результат выражения != 0 не обязательно есть 1. Поэтому тот, кто писал t += p<5, явно чудак

[jcxz]

А еще результат выражения != 0 не обязательно есть 1. Поэтому тот, кто писал t += p<5, явно чудак

Я об этом писал ещё в 10-м посте:

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

[Сергей Борщ]

А еще результат выражения != 0 не обязательно есть 1.

Обязательно есть.

Поэтому тот, кто писал t += p<5, явно чудак

Тот, кто писал этот код, очень хорошо знал Стандарт языка. В отличие от вас.

6.5.8 Relational operators
6 Each of the operators < (less than), > (greater than), <= (less than or equal to), and >=
(greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false.⁸⁹⁾
The result has type int.
6.5.9 Equality operators
The == (equal to) and != (not equal to) operators are analogous to the relational
operators except for their lower precedence.⁹⁰⁾ Each of the operators yields 1 if the
specified relation is true and 0 if it is false. The result has type int.

[Arlleex]

Обязательно есть.
Тот, кто писал этот код, очень хорошо знал Стандарт языка. В отличие от вас.

Вон оно как? Стандартов не читал, да, признаю.
Но вот будет ли так в дальнейшем - не совсем ясно, поэтому так писать лично я бы не стал. Ведь компиляторы все новее и новее, а оптимизация все хитрее. Никто не знает, во что это выльется в будущем.

[jcxz]

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

Я тоже выше об этом писал. Понятно что сейчас это работает. Но такой подход и стиль считаю плохим.
char тоже раньше всегда был знаковым, а сейчас может быть и беззнаковым, в зависимости от установок компилятора. Всё потому, что в появились некоторые CPU, в которых чтение/запись беззнаковых char короче чем знаковых, и во многих случаях, когда знаковость не важна, лучше использовать такие операции чтения/записи.
Так и с этим - если CPU позволяет более эффективно работать с типами bool со значениями 0/-1, а не 0/1, то лучше так и делать, разрешив спец.опцией компилятора. Хотя конечно это гораздо менее часто встречающаяся потребность чем char, значит не очень важная.

[Arlleex]

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

Про CPU с различными подходами в копировании char не знал, спасибо. Интересно конечно, как это может так быть - ведь копируются 8 бит все равно...

А вот размышления вслух, можно сказать.
Допустим есть условие if(x != y) или просто выражение z = (x != y). Переменные целые. Я бы на месте компилятора сделал что-то наподобие z = x - y или z = x ^ y. И если z равно 0, то это значило, что x == y. А если не равно 0, то, соответственно, x != y. Вот типичный случай, когда не нужны были бы лишние телодвижения по установке значения 1 в переменную вместо прямого присваивания результата вычитания. Меньше инструкций ведь по факту. И таких примеров оптимизаций, ИМХО, можно как-то еще придумать. Опять же, просто исходя из логики рассуждаю

Сообщение отредактировал Arlleex - Aug 25 2018, 07:42