CPP enum с минусовыми значениями, насколько это правильно Опции

[AlexRayne]

Скорее не вкуса, а стиля. Заглавными символами принято описывать неизменяемые сущности типа констант, литералов.

Сразу видно, где переменные, а где константы/литералы. Устоявшийся стиль. Стараюсь придерживаться его.

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

[jcxz]

The compiler will use the smallest type required to hold enum constants, preferring

Это всё известно и хорошо. Но, по уму, должно касаться только правил хранения этого enum. Т.е. - какого размера память выделить для его хранения. А не касательно аргументов функций передаваемых в регистрах. При передаче аргумента в регистре, он занимает весь регистр, и расширение байт->слово в таком случае - совершенно бессмысленная операция. Да ещё выполняемая перед каждым использованием значения этого enum-а.
Конечно можно сделать: int x = x_enum; в начале функции, но опять теряется удобство отладки

[sigmaN]

Ну тогда надо конкретизировать на примерах.
Я так понимаю, что если для энума(для его хранения как вы говорите) будет выбран тип uint8_t то и аргумент функции тоже будет uint8_t и передача аргумента этой функции должна быть выполнена по тем-же правилам, что и передача аргумента с типом uint8_t. Как-то слишком уж глупо нечто, что хранится как uint8_t передавать в функцию по правилам uint16_t...

Конкретизируем.
STM8, IAR, функция с одинм аргументом.
По правилам передачи аргументов 8ми битные передаются через регистр А, 16ти битные через регистр X
Вы утрерждаете, что enum будет передан через регистр X не смотря на то, что в памяти будет занимать 8бит.
Правильно я понял ход ваших мыслей?

Код

typedef enum{
  TEST1,
  TEST2
} testEnum_t;

volatile testEnum_t te = TEST1; //to avoid inlining and optimizations

void testF(testEnum_t enm)
{
  nop();
    
  switch(enm)
  {
  case TEST1: GPIOA->ODR = 0;
    break;
  case TEST2: GPIOA->ODR = 0xff;
    break;
  }
  nop();
}



int main()
{
  testF(te);
}

Код

   327            testF(te);
   \   000008 C6 ....      LD        A, L:te
   \   00000B 9D           NOP
   \   00000C 27 09        JREQ      L:??main_0
   \   00000E 4A           DEC       A
   \   00000F 26 0A        JRNE      L:??main_1
   \   000011 35 FF 5000   MOV       L:0x5000, #0xff
   \   000015 20 04        JRA       L:??main_1
   \                     ??main_0:
   \   000017 725F 5000    CLR       L:0x5000
   \                     ??main_1:
   \   00001B 9D           NOP

Всё замечательно, аргумент функции в виде энума использует 8ми битный регистр A ибо весь энум помещается в 8бит.

исправляем так, чтоб энум стал 16бит. Всё остальное не меняем

Код

typedef enum{
  TEST1,
  TEST2 = 1024
} testEnum_t;

компилируем....

Код

    327            testF(te);
   \   000008 CE ....      LDW       X, L:te
   \   00000B 9D           NOP
   \   00000C 27 0B        JREQ      L:??main_0
   \   00000E 1D 0400      SUBW      X, #0x400
   \   000011 26 0A        JRNE      L:??main_1
   \   000013 35 FF 5000   MOV       L:0x5000, #0xff
   \   000017 20 04        JRA       L:??main_1
   \                     ??main_0:
   \   000019 725F 5000    CLR       L:0x5000
   \                     ??main_1:
   \   00001D 9D           NOP

используется регистр X.

[jcxz]

Я так понимаю, что если для энума(для его хранения как вы говорите) будет выбран тип uint8_t то и аргумент функции тоже будет uint8_t и передача аргумента этой функции должна быть выполнена по тем-же правилам, что и передача аргумента с типом uint8_t. Как-то слишком уж глупо нечто, что хранится как uint8_t передавать в функцию по правилам uint16_t...

Глупо - это если сказано про расширение размера данных не понимать, что речь естественно идёт не о 8-битной архитектуре. Я говорил про 32-битный IAR for ARM.
И я написал: аргумент функции типа enum, а не u8 или u16.

[sigmaN]

Вот и я гворю: уточнять надо. Кто куда и кого расширяет.

Пока, кстати, не видно разницы между аргументами i8 i16 i32 и энумами с соответствующими размерами.... Но IAR для ARM у меня под рукой нет.