Я считаю, что "лишние" скобки не нарушат работу компилятора и не будут в самом деле лишними, даже если программер назубок помнит все приоритеты операций. В конце концов, читаемость исходника будет лучшей. Даже если не заботиться о переносимости.
Бессмысленное утверждение. Примерно как утверждать, что брюнетки лучше блондинок. Это дело вкуса. Если для вас толпа скобок в строке улучшает читаемость, то для другого - ухудшает.
ну да, ну да... один и тот же код с -lto в одной версии компилятора собирается нормально и работает, а после сборки в более новой версии компилятора получается 0 байт исполняемого кода... виноват, конечно программист, но не тот, что код писал, а тот, что писал компилятор
Приведите пример такого кода. Иначе - это пустой трёп.
PS: Кто-то видит летающие тарелки с зелёными человечками. Но не может привести доказательств. Кто-то - корректный код, который не компилится правильно компилятором. Но не может его показать. Это примерно из одной оперы....
Пример кода? У меня проект из пары десятков файлов, и публиковать их я не имею желания. LTO от версии к версии avr-gcc дает абсолютно разные результаты: может обнулять выхлоп, может давать полностью рабочий файл минимального размера, а может выдать полностью нерабочий вариант. Можете не верить (см. ранее о вере), мне пофиг.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Если требуется определённый порядок выполнения операций с равным приоритетом, то используют скобки. Знаете такие символы ()? Дичь - это писать без них. А оптимизатор легко упростит, если захочет, потому что ему абсолютно похер, что это программист решил какую-то цифру в числе выделить.
Опять бред несёте... Вам бы учебник по си почитать что-ли? Который сами же рекомендовали выше. Язык си чётко регламентирует как приоритеты операций, так и направление их выполнения на разных уровнях приоритета. В выражении display % 1000 /100 все операции имеют одинаковый приоритет и направление выполнения - слева направо. И никаких оптимизаций вменяемый оптимизатор здесь не сделает.
А скобки где ни попадя, городят только неумехи, не сумевшие прочитать и усвоить порядок приоритета и направление операций.
Вообще-то, в данном выражении имеются константы. Свёртка констант в выражениях является наиболее простым видом оптимизации. Поэтому данное выражение компилятор вероятно сведёт к выражению display % 10. Или нет?
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
.Если для вас толпа скобок в строке улучшает читаемость, то для другого - ухудшает.
Типичный пример демагогии: утверждение оппонента преувеличить до бесконечности, доведя до абсурда. Я не практиковал "толпу скобок", равно как и выражение на пол-страницы. Разбивал сложное выражение на части, использовал вспомогательные переменные, благо дефицита оперативной памяти не наблюдается. Трудно представить программу, где все вычисленные части выражения используются только однократно, практически в разных местах кода можем использовать уже вычисленные фрагменты. И скобки нисколько не мешали.
Такой подход и в цикл легко превратить, и работает с любым количеством разрядов...
P.P.S.
Вот пример такого подхода уменя - как-то делал по-быстрому по просьбе человека, который где-то разобыл табло для электронных очередей (с большими семисегментниками) и хотел сделать из этого часы. Там ещё в этой функции и нули лишние не рисуются, если число маленькое получилось, и знак минуса поддерживается.
Последний раз редактировалось WiseLord Ср фев 14, 2024 20:58:36, всего редактировалось 3 раз(а).
Такой подход и в цикл легко превратить, и работает с любым количеством разрядов...
Ваш код тоже не ахти. Зачем для каждого разряда 2 деления? Деление - плохая операция. Даже на тех МК, где она аппаратно есть, выполняется очень медленно. Всё ведь просто:
Зачем для каждого разряда 2 деления? Деление - плохая операция. Даже на тех МК, где она аппаратно есть, выполняется очень медленно.
Потому что это: - легко читается и понимается - может оптимизироваться компилятором так, что делений там и не будет. - такой код вполне уместен при выводе результатов на экран, будучи вызываем один раз в главном цикле. В критичных местах вроде прерываний - да, делить лучше не стоит.
Например, анализируя листинг, я как-то видел что деление 8-битного числа 'num' на константу 10 компилятор обычно преобразует в умножение на 205 и сдвиг:
Код:
// Например, num = 234
// Написано программистом digit = num % 10 # digit = 234 % 10 = 4 num /=10 # num = 234 / 10 = 23
Деление числа на 10 равносильно его умножению на 204.8 и последующему делению на 2048 (он же сдвиг вправо на 11 разрядов). А если умножать не на 204.8, а на 205 - результат для целых чисел будет эквивалентным, по крайней мере в диапазоне 0..255 (P.S. а на самом деле - даже в диапазоне 0..1028).
Для чисел большей разрядности можно тоже подобрать (и компиляторы это часто умеют) такие числа, которые будут давать правильный результат.
P.S.
Кстати, попробовал ваш совет применить в вышеуказанном проекте, и... фиаско:
"До" - размер бинарника прошивки 1290 байт:
Код:
for (i = 0; i < DIGITS; i++) { if (number == 0 && i > dot) break; ind[i] = num[number % 10]; number /= 10; }
После - размер бинарника прошивки 1372 байта:
Код:
for (i = 0; i < DIGITS; i++) { if (number == 0 && i > dot) break; uint16_t i10 = number / 10; ind[i] = num[number - i10 * 10]; number = i10; }
После "оптимизации" прошивка стала больше на 82 байта.
P.P.S.
Целочисленное деление на 10 вовсе не добавляет "ещё одно деление". Раз уж при вычислении остатка от деления число уже было один раз поделено на 10 (и промежуточный результат деления был помещён в какой-то регистр), второй раз комплиятор этого делать не будет, и num /= 10 сведётся просто к забиранию из этого регистра готового результата.
Как видно - всего 22 байта как в 1-м так и во 2-м случае. Как у вас получилось почти 1.5 КБ - ума не приложу.
Да, в этом случае компилятор догадался, что команду UDIV можно использовать только одну. И в этом случае разницы между вариантами нет. Но компилятор не всегда такой догадливый. В более сложных функциях он не всегда догадывается до этого. И тогда вариант 2 получается и меньше и быстрее.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения