switch и последовательность нескольких case

Не помню каст работает из шапки или нет так что Harald i-rinat beastie

Это эквивалентный код. Так что хорошо бы расписать, что подразумевается под «насколько плохо».

Да, посмотрел gcc/clang -S. Всё абсолютно одинаково. Я просто подумал что такой switch может развернутся не в таблицу переходов, а в if/else какой. Не можно вроде как заставить так развернутся свич, короче думал что на вид хоть эквивалент, но на деле нет. Вопрос больше в том что это в стандарте прописано точно или это на усмотрение компилятора во что такое превращать. Эту информацию я не нашёл.

пиши первым вариантом

только не в одну строчку, а каждый case на своей, для читабельности

Из шапки не сработало, но тут да. Код эквивалентный, насколько я ещё помню сишку. Отталкивайся от читабельности. Отталкиваясь от данного примера, я бы предпочёл:

switch(ch)
{
    case '%': /* FALLTHROUTH */
    case '$': /* FALLTHROUTH */
    case '#':
        foo(ch);
        break;
    case '!':
        bar(ch);
        break;
}

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

Ага, спасибо.

Ну, да, где оно уместно и не длинно так и буду. Спасибо

Что же, буду иметь в виду и иногда проверять, если не забуду =)

для читабельности

500 строк «читабельности» :)

тогда такой код надо генерировать автоматически и не пытаться читать его

оба варианта функционально эквивалентны, но второй будет преобразован в первый при оптимизации, поскольку кода меньше.

первый вариант предпочтительней из-за читабельности(надо только отформатировать нормально).

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

но поскольку конструкции вида

switch (x) {
case 0: .... break;
case 10000: .... break;
default: break;
}

при табличной реализации даст таблицу в 10000 переходов, где заполнены только два, то для экономии памяти компилятор будет генерить код в виде двух if:

if(x == 0) {...}
else if (x == 10000) {...}
else {}

могут быть смешаные случаи типа

switch (x) {
case 0: .... break;
case 1: .... break;
case 2: .... break;

case 10000: .... break;
case 10001: .... break;
case 10002: .... break;
default: break;
}

в принципе может генериться как два switch оператора, то есть будут две короткие таблицы.

if(x<10000) {
  switch (x) {
  case 0: .... break;
  case 1: .... break;
  case 2: .... break;
  }  
else {
  switch(x){
  case 10000: .... break;
  case 10001: .... break;
  case 10002: .... break;
  }
}

также короткий(мало вариантов) switch типа

  switch(x){
  case 10000: .... break;
  case 10001: .... break;
  }

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

И такой код можно делать читабельным. Место на диске дешёвое. Лишний перевод строки не помешает.

Еще может рукодельную таблицу переходов в if’ы переделать.

Во, спасибо. Тогда есть смысл наверное ещё до switch сделать табличку где translate_table[raw_value] = index++;... и в switch уже отдавать так switch(translate_table[raw_value]) тогда в switch будет уже попадать ровная последовательность без скачков и по идее ничто не должно мешать уже генерировать чисто таблицу переходов без всяких там этих вот.

Premature optimization is the root of all evil. Компиляторы умнее нас, пусть они и работают. KISS

«Преждевременная оптимизация - корень…»

При этом эту оптимизацию современные компиляторы сделают на порядки эффективнее, чем неопытный программист. Лучше пиши саму программу.

case '%': case '$': case '#':

Тяжко будет читать такое, особенно под конец рабочего дня.

В таком случае можно вместо switch прописать таблицу самому. Отдав switch только обработку состояний

table[STATES][SIGNALS]=
{
   [STATE_1][SIGNAL_1]= STATE_2,
   [STATE_1][SIGNAL_2]= STATE_ERROR,
   [STATE_2][SIGNAL_2]= STATE_3,
   [STATE_2][SIGNAL_1]= STATE_ERROR,

}

while((signal=get_data())
{
   prev_state = state
   state = table[state][signal];
   switch(state)
   {
      case STATE_2: do_state_2(); break;
      case STATE_3: do_state_3(); break;
      case STATE_ERROR: do_error(prev_state,state,signal); break;
   }
}

Только вот если сигналов и/или состояний детяток то table будет огромная задолбаешься её описывать.

псевдокод простого табличного(самый эффективный) switch выглядит так

if(x < min_case) goto __default_branch;
if(x > max_case) goto __default_branch;
goto @__jumps_table[x-min_case]; ///тут берется из таблицы адрес нужного бренча и туда осуществяется переход.

то есть для всех вариантов скорость одинакова.

Это для примера, это не работа, там будут идентификаторы из enum а может и не будут :D

:D Я не из расчёта оптимизировать, я типа что-бы не мешать оптимизировать.

Ладна :(

Ясно, спасибо. Ну значит если свич не на 1500 строк можно не парится. Само разрулит =)

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

Молчу, не спорю. Всё верно :3

Ясно, спасибо. Ну значит если свич не на 1500 строк можно не парится. Само разрулит =)

проблема табличного свича - в размере таблицы, то есть разнице между case_max и case_min значениями.

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

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

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

=)