1) Оператор switch построен на основе if
2) Оператор if будет быстрее
3) Просто оператор switch в некоторых случаях более удобный.
Я прав?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > switch && if |
| Автор: Kirgston 8.3.2009, 11:08 |
| Всем доброго времени суток! Итак... вчера я сидел и думал... какой же оператор будет работать быстрее? Да я понимаю что это практически ... ну минимальная оптимизация. Но всё же! Давайте подумаем как работает switch. Он проверяет переменную на равенство числу и если они равны делает блок операторов... так вот. Он же проверяет! Он же не угадывает и т.д. а значит по логике он работает по принципу if . Делая с этого вывод можно сказать что: 1) Оператор switch построен на основе if 2) Оператор if будет быстрее 3) Просто оператор switch в некоторых случаях более удобный. Я прав? |
| Автор: bilbobagginz 8.3.2009, 11:28 |
| если критерий - время работы, то для идентичного функционала - и if, и switch будут в результате компиляции приведены к единому варианту. if - это не оператор, как и switch. это т.н. утверждения, состоящие из ключевыз слов и "выражений". т.е. само по себе if - бессмысленное ключевое слово, а не оператор. в контексте Си, 'оператор' "при включении" имеет значение. if или switch не имеют. |
| Автор: Kirgston 8.3.2009, 11:38 |
| Ах да... я забыл... начал думать в логику С++ ))) и забыл что в итоге это всё итак асм код =) Так что ... хе хе =) пардон просто не учёл. |
| Автор: _Dimon_ 8.3.2009, 12:35 |
| хотя в итоге может одно и тоже, но конечно switch намного удобней чем множественные ифы, и я думаю с этим никто не будет спорить |
| Автор: maxim1000 8.3.2009, 12:42 |
| в принципе, у компилятора больше свободы для оптимизации switchиз-за накладываемых ограничений например, switch на 100 вариантов можно попробовать привести к бинарному поиску, т.к. используютсятолько интегральные константы, т.е. их можно сравнивать, и они известны на этапе компиляции Добавлено через 47 секунд возможно, конечно, компилятор распознает и эквивалентную последовательность if-ов, еслиона соответствует ограничениям, но это, по-моему, очень маловероятно |
| Автор: Lazin 8.3.2009, 12:58 |
| нужно писать код исходя из того, что его будут читать другие люди, т.е. код должен быть читаемым, а не "быстрым", многоэтажные switch-и и if-ы лучше стараться избегать, если в программе появляется необходимость написать switch, на 30 вариантов, то это признак неправильного проектирования приложения(невсегда конечно, но часто), к примеру, с помощью switch иногда пытаются реализовать полиморфизм, хотя для этого лучше использовать виртуальные ф-ии... |
| Автор: GoldFinch 8.3.2009, 13:07 |
| if - последовательное сравнение или бинарный поиск switch - таблицы или бинарный поиск в ряде случаев switch и if компилируются одинакого |
| Автор: azesmcar 8.3.2009, 15:29 | ||||
switch (если его правильно написать) может работать быстрее благодаря таблице переходов. т.е. компилятор может его оптимизировать в http://en.wikipedia.org/wiki/Jump_table. Также посмотри http://en.wikipedia.org/wiki/Duff%27s_device который копирует массив с помощью switch -а. По ссылкам пройди, там хорошо описано
с подобным утверджением я бы поспорил..В большинстве случаев - да! но не во всех. Возможны ситуации когда вам нужна ооочень высокая производительность..и тогда вам хочешь не хочешь а придется повышать производительность за счет нечитабельного кода...комментарии то никто не отменял 
с этим согласен  |
| Автор: mes 8.3.2009, 15:49 | ||
Вы забыли как минимум еще один пункт: 4) Кесарю кесарево. if и switch не взаимозаменяемы, у каждого из них своя область применения. Там где можно использовать switch, лучше использовать именно его. Помимо if и switch существует еще ?: |
| Автор: azesmcar 8.3.2009, 15:56 | ||
да и кстати Kirgston тернарный оператор и if тоже немного различаются..?: может работать compile-time, if - нет, благодаря чему тернарный оператор успешно используется в http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5. |
| Автор: Lazin 8.3.2009, 16:32 | ||||||
прежде чем написать нечитаемый но быстрый код, нужно написать читаемый, но медленный, выяснить почему он медленный и исправить это
по твоему
|
| Автор: inside_pointer 8.3.2009, 16:34 |
| в switch тяжело выходить из цикла и они совсем по-разному условия проверяют (множественные if'ы проверяют истинность условия, а switch проверяет совпадение) |
| Автор: azesmcar 8.3.2009, 20:55 | ||||
не спорю  преждевременная оптимизация - зло.
Зависит от того о чем мы говорим, если говорить о C++ то в принципе да, отключите оптимизацию и он ее выполнит.. Но если включить, оптимизатор наверняка вырежет эту проверку. |
| Автор: 0xDX 8.3.2009, 21:43 |
| до 10 сравнений, не будет иметь значение с чем воспользоваться, а иначе уже можно начинать делать полиморфизм......... Или искать закономерность. P.S полиморфизм - это не только виртуальные функции.... |
| Автор: mes 9.3.2009, 10:32 | ||||
т.е если больше 10 то разница будет заметна ?! и на чьей стороне преимущество ?
Нельзя ли тут поподробнее ? как для динамического сравнения полиморфизм даст выгоду в скорости ? |
| Автор: maxim1000 9.3.2009, 14:50 | ||
как уже говорили "кесарю кесарево" там, где полиморфизм хорошо ложится на задачу, он даёт константное время выбора варианта (длятех же виртуальных функций: взять указатель на таблицу виртуальных функций, оттуда указатель на функцию и вызвать её), а набор сравнений - линейное, в лучшем случае логарифмическое |
| Автор: mes 9.3.2009, 15:10 | ||||
и
имхо, отражают совершено разный взгляд на вещи, поэтому я и пострался, уточнить что именно подразумевает 0xDX под вышесказанным |
| Автор: vinter 9.3.2009, 15:35 |
| считаю еще стоит обсудить превосходство &1 над %2. |
| Автор: Lazin 9.3.2009, 16:53 | ||
уже где-то обсуждали) |
| Автор: vinter 9.3.2009, 17:33 |
| Lazin, switch с if'ми тоже. Это не мешает появлению подобных тем. Русскоговорящие оптимизаторы настолько суровы, что оптимизирует вещи, которые оптимизировать не неадо. |
| Автор: GoldFinch 9.3.2009, 18:04 |
| очевидно же, что остаток от деления медленнее чем И |
| Автор: mes 9.3.2009, 18:23 | ||
Неочевидно , так же как и то что >>1 быстрее /2. На то и оптимизаторы Можно лишь с достаточной долей уверенности сказать, что "зависимыe" (>>,<< и &) варианты не медленнее. |
