Вопросы по С/С++ (СИ)

VladislavS

Куда предлагаете скобки поставить?

Реклама

Martian

Реклама

jcxz

Я считаю, что "лишние" скобки не нарушат работу компилятора и не будут в самом деле лишними, даже если программер назубок помнит все приоритеты операций. В конце концов, читаемость исходника будет лучшей. Даже если не заботиться о переносимости.

Бессмысленное утверждение. Примерно как утверждать, что брюнетки лучше блондинок. Это дело вкуса. Если для вас толпа скобок в строке улучшает читаемость, то для другого - ухудшает.

Добавлено after 6 minutes 17 seconds:

ARV писал(а):

ну да, ну да... один и тот же код с -lto в одной версии компилятора собирается нормально и работает, а после сборки в более новой версии компилятора получается 0 байт исполняемого кода... виноват, конечно программист, но не тот, что код писал, а тот, что писал компилятор

Приведите пример такого кода. Иначе - это пустой трёп.

PS: Кто-то видит летающие тарелки с зелёными человечками. Но не может привести доказательств.
Кто-то - корректный код, который не компилится правильно компилятором. Но не может его показать.
Это примерно из одной оперы.... :dont_know:

Реклама

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

ARV

Пример кода? У меня проект из пары десятков файлов, и публиковать их я не имею желания. LTO от версии к версии avr-gcc дает абсолютно разные результаты: может обнулять выхлоп, может давать полностью рабочий файл минимального размера, а может выдать полностью нерабочий вариант.
Можете не верить (см. ранее о вере), мне пофиг.

Реклама

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Bill_

jcxz писал(а):

Martian писал(а):

Если требуется определённый порядок выполнения операций с равным приоритетом, то используют скобки. Знаете такие символы ()? Дичь - это писать без них. А оптимизатор легко упростит, если захочет, потому что ему абсолютно похер, что это программист решил какую-то цифру в числе выделить.

Опять бред несёте... Вам бы учебник по си почитать что-ли? Который сами же рекомендовали выше.

Язык си чётко регламентирует как приоритеты операций, так и направление их выполнения на разных уровнях приоритета.
В выражении display % 1000 /100 все операции имеют одинаковый приоритет и направление выполнения - слева направо. И никаких оптимизаций вменяемый оптимизатор здесь не сделает.

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

Вообще-то, в данном выражении имеются константы. Свёртка констант в выражениях является наиболее простым видом оптимизации. Поэтому данное выражение компилятор вероятно сведёт к выражению display % 10. Или нет?

Реклама

Реклама

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Jack_A

jcxz писал(а):

.Если для вас толпа скобок в строке улучшает читаемость, то для другого - ухудшает.

Типичный пример демагогии: утверждение оппонента преувеличить до бесконечности, доведя до абсурда. Я не практиковал "толпу скобок", равно как и выражение на пол-страницы. Разбивал сложное выражение на части, использовал вспомогательные переменные, благо дефицита оперативной памяти не наблюдается. Трудно представить программу, где все вычисленные части выражения используются только однократно, практически в разных местах кода можем использовать уже вычисленные фрагменты. И скобки нисколько не мешали.

Цитата:

Бессмысленное утверждение

Цитата:

это пустой трёп.

Чувствуется рука мастера. Э.Дейкстра, это Вы?? :))

Реклама

VladislavS

Bill_ писал(а):

Или нет?

А вы как думаете? Свернёт или нет?

Реклама

Bill_

VladislavS писал(а):

Bill_ писал(а):

Или нет?

А вы как думаете? Свернёт или нет?

Если написать так: display % (1000/100), то сворачивает. Если скобки убрать, то - нет. Компилятор - IAR STM8.

Реклама

VladislavS

А как правильно? Сворачивать или нет?

Добавлено after 1 minute 26 seconds:
И полагаете ли вы что со скобками это то же самое выражение?

Реклама

WiseLord

Конечно же нет

Правильный результат для display % 1000 /100

Код:

12345 % 1000 /100 = 345 / 100 = 3

Если внезапно (с чего бы вдруг) это сворачивать до display % 10, получим просто 5.

Другое дело, что хороший компилятор может это упростить до display / 100 % 10

Код:

12345 / 100 % 10 = 123 % 10 = 3

Результат будет всегда верным, но числа немного меньшие - вычисления могут быть теоретически быстрее.

P.S. Но вообще, ранее приведённый код - плохой, так как в нём вычисления для каждого разряда разные:

Код:

PORTD = ~((SEGMENTE[display % 1000/100])); 
PORTD = ~(SEGMENTE[display % 100/10]);
PORTD = ~(SEGMENTE[display % 10]);

Лучше выводить числа справа налево, тогда там для любого разряда нужно делать лишь %10 и /10, то есть, что-то вроде:

Код:

PORTD = ~(SEGMENTE[display % 10]); # разряд единиц
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд десятков
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд сотен
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд тысяч

Такой подход и в цикл легко превратить, и работает с любым количеством разрядов...

P.P.S.

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

jcxz

Bill_ писал(а):

Поэтому данное выражение компилятор вероятно сведёт к выражению display % 10. Или нет?

Да ужж.... не думал, что на данном форуме так плохо с математикой начальных классов средней школы... печалька :dont_know:

Добавлено after 8 minutes 5 seconds:

WiseLord писал(а):

Лучше выводить числа справа налево, тогда там для любого разряда нужно делать лишь %10 и /10, то есть, что-то вроде:

Код:

PORTD = ~(SEGMENTE[display % 10]); # разряд единиц
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд десятков
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд сотен
display /= 10;
PORTD = ~(SEGMENTE[display % 10]); # разряд тысяч

Такой подход и в цикл легко превратить, и работает с любым количеством разрядов...

Ваш код тоже не ахти.
Зачем для каждого разряда 2 деления? Деление - плохая операция. Даже на тех МК, где она аппаратно есть, выполняется очень медленно.
Всё ведь просто:

Код:

uint i0 = display / 10;
uint digit0 = display - i0 * 10;
uint i1 = i0 / 10;
uint digit1 = i0 - i1 * 10;
...

Всего по одному делению на разряд. На ARM такой код будет гораздо быстрее.

WiseLord

jcxz писал(а):

Зачем для каждого разряда 2 деления? Деление - плохая операция. Даже на тех МК, где она аппаратно есть, выполняется очень медленно.

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

Например, анализируя листинг, я как-то видел что деление 8-битного числа 'num' на константу 10 компилятор обычно преобразует в умножение на 205 и сдвиг:

Код:

// Например, num = 234

// Написано программистом 
digit = num % 10         # digit = 234 % 10 = 4
num /=10                 # num = 234 / 10 = 23

// Оптимизировано компилятором 
tmp = (num * 205) << 11; # tmp = (234 * 205) << 11 = 47970 << 11 = 23
digit = num - tpm * 10;  # digit = 234 - 23 * 10 = 234 - 230 = 4
num = tmp;               # num = 23

Что за магическое число 205?

Деление числа на 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 сведётся просто к забиранию из этого регистра готового результата.

Martian

WiseLord, может, компактней будет использовать div_t - в этом случае, скорее всего, всё обернётся в функцию и её вызовы.

VladislavS

WiseLord, код не оптимизируют по размеру бинарника. Надо листинг для целевой платформы смотреть.

jcxz

WiseLord писал(а):

Кстати, попробовал ваш совет применить в вышеуказанном проекте, и... фиаско:

"До" - размер бинарника прошивки 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 байта.

Почти 1.5 КБ на таком простейшем коде??? Серьёзно??? :shock:

Как вы такого добились?
Попробовал скомпилить в IAR:

Код:

enum {DIGITS = 6};
static u8 ind[DIGITS];
static u8 const num[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'};
#if 0
void f1(uint number, uint dot)
{
  for (uint i = 0; i < DIGITS; i++) {
    if (number == 0 && i > dot) break;
    ind[i] = num[number % 10];
    number /= 10;
  }
}
#else
void f2(uint number, uint dot)
{
  for (uint i = 0; i < DIGITS; i++) {
    if (number == 0 && i > dot) break;
    uint i10 = number / 10;
    ind[i] = num[number - i10 * 10];
    number = i10;
  }
}
#endif

Результаты:
1-й вариант:

Код:

          void f1(uint number, uint dot)
          {
            for (uint i = 0; i < DIGITS; i++) {
                  _Z2f1jj: (+1)
00000000   0x2200             MOVS     R2,#+0
00000002   0x230A             MOVS     R3,#+10
              if (number == 0 && i > dot) break;
                  ??f1_0: (+1)
00000004   0xB908             CBNZ.N   R0,??f1_1
00000006   0x4291             CMP      R1,R2
00000008   0xD304             BCC.N    ??f1_2
              ind[i] = num[number % 10];
              number /= 10;
            }
                  ??f1_1: (+1)
0000000A   0x1C52             ADDS     R2,R2,#+1
0000000C   0x2A06             CMP      R2,#+6
0000000E   0xFBB0 0xF0F3      UDIV     R0,R0,R3
00000012   0xD3F7             BCC.N    ??f1_0
          }
                  ??f1_2: (+1)
00000014   0x4770             BX       LR               ;; return

2-й:

Код:

          void f2(uint number, uint dot)
          {
            for (uint i = 0; i < DIGITS; i++) {
                  _Z2f2jj: (+1)
00000000   0x2200             MOVS     R2,#+0
00000002   0x230A             MOVS     R3,#+10
              if (number == 0 && i > dot) break;
                  ??f2_0: (+1)
00000004   0xB908             CBNZ.N   R0,??f2_1
00000006   0x4291             CMP      R1,R2
00000008   0xD304             BCC.N    ??f2_2
              uint i10 = number / 10;
              ind[i] = num[number - i10 * 10];
              number = i10;
            }
                  ??f2_1: (+1)
0000000A   0x1C52             ADDS     R2,R2,#+1
0000000C   0x2A06             CMP      R2,#+6
0000000E   0xFBB0 0xF0F3      UDIV     R0,R0,R3
00000012   0xD3F7             BCC.N    ??f2_0
          }
                  ??f2_2: (+1)
00000014   0x4770             BX       LR               ;; return

Как видно - всего 22 байта как в 1-м так и во 2-м случае. Как у вас получилось почти 1.5 КБ - ума не приложу.

Да, в этом случае компилятор догадался, что команду UDIV можно использовать только одну. И в этом случае разницы между вариантами нет. Но компилятор не всегда такой догадливый. В более сложных функциях он не всегда догадывается до этого. И тогда вариант 2 получается и меньше и быстрее.

VladislavS

Пятничная затравка Код.

Для беззнаковых

Код:

void Num2Segs(std::unsigned_integral auto number)
{
  for(auto i=DIGITS; i; )
  {   
    if(number || i==DIGITS)
    {
      auto dv = div(number,10);
      ind[--i] = Dig2Seg[dv.rem];
      number = dv.quot;
    }
    else ind[--i] = 0;
  }  
}

Перегрузка для знаковых

Код:

void Num2Segs(std::signed_integral auto number)
{
  for(auto &x : ind) x=0;  
  bool neg = number<0;
  auto tmp = neg ? -number : number;
  for(auto i=DIGITS; i>(neg?1:0); )
  {   
    if(tmp || i==DIGITS)
    {
      auto dv = div(tmp,10);
      tmp = dv.quot;      
      ind[--i] = Dig2Seg[dv.rem];
      if(neg && (tmp==0 || i==1))
      {
        ind[--i]= Dig2Seg[10]; // минус
        break;
      }      
    }
    else --i;
  }
}

jcxz

VladislavS писал(а):

Пятничная затравка Код.

Для беззнаковых
...
Перегрузка для знаковых
...

Ну всё - блоха подкована. :)))

Лишь бы скакать после этого смогла.

VladislavS

Скорее воробьи постреляны.

WiseLord

jcxz писал(а):

Почти 1.5 КБ на таком простейшем коде??? Серьёзно??? :shock:

Нет, конечно. Это целиком весь проект часов https://github.com/WiseLord/clock7segm

Смотрите не на абсолютное значение, а на разницу.

VladislavS

WiseLord, хотел посмотреть откуда 82 байта, а функция segmNum в коде вообще не используется.

Добавлено after 1 hour 13 minutes 40 seconds:
Забил функцию в Compiler Explorer. Было.

Немного поработал с типами. Стало.

Вот теперь можно попробовать разные варианты. Не забыть оптимизацию O2 и O3 попробовать - там интереснее.

Вопросы по С/С++ (СИ)

Кто сейчас на форуме