Здравствуйте, _hum_, Вы писали:
__>Всегда полагал, что семантика switch/case/case/... аналогична if/if/if/... без break-а и if/else if/else if/... c break-ом. А тут решил не ставить break "в конце ветки выбора", и опля — сюрприз. Так что, товарищи, кто еще так же, как и я, заблуждался, будьте внимательны:
Надо было быть внимательным еще в школе, когда бэйсик на z80 теребил
__>p.s. Вопрос к знатокам — зачем такая неочевидная и "техническая" семантика?
С чего это она неочевидная? Всё вполне логично тут. Есть if и есть switch и они обязаны себя вести по разному, ибо в противном случае чтото из них не нужно.
switch полезен тем, что можно писать так, что код сможет выполняться не полностью. Например каттотак
switch(flag)
{
case doFullWork: { checkLastWork(); clearTemp(); }
case doOptimizedWork: { clearCaches(); }
case justDoIt: { doWork(); }
}
Здравствуйте, _hum_, Вы писали:
__>кхм.. а почему тогда сопроводили свой пример текстом "на всякий случай, а то ещё скажите, что не видели: "? обычно такой коммент постят к "каноническим" вещам, которые не знать стыдно...
Это канонический приём любителей макросов. Можно даже сказать, не побоюсь этого слова, паттерн.
__>>>чтобы показать, что со свитчем он проще? BFE>>А разве он проще? __>да, места меньше занимает (нет кучи сравнений и скобок)
Тут я потерял нить рассуждений.
Здравствуйте, _hum_, Вы писали:
__>2) нигде в литературе я не видел, чтобы кто-то обращал на это внимание (соответственно, я только теперь столкнулся с этим)
Значит вы не читали Страуструпа.
Здравствуйте, Sheridan, Вы писали:
S>Есть if и есть switch и они обязаны себя вести по разному
Они и ведут себя по разному. Ифы — набор произвольных условий, свитчи — выбор подходящего значения для одного выражения.
А вот в чью светлую голову пришло решение скрестить оператор выбора с оператором безусловного перехода...
S>switch полезен тем, что можно писать так, что код сможет выполняться не полностью. Например каттотак S>
S>switch(flag)
S>{
S> case doFullWork: { checkLastWork(); clearTemp(); }
S> case doOptimizedWork: { clearCaches(); }
S> case justDoIt: { doWork(); }
S>}
S>
Жуть. Goto в худшем виде.
Вообще, конструкция switch в том виде, в каком она есть в С/C++, фундаментально ущербна. На мой взгляд, это один из крупных фейлов в языкостроении. Хуже, наверное, только нуллабельные указатели.
Здравствуйте, AlexRK, Вы писали:
S>>switch полезен тем, что можно писать так, что код сможет выполняться не полностью. Например каттотак S>>
S>>switch(flag)
S>>{
S>> case doFullWork: { checkLastWork(); clearTemp(); }
S>> case doOptimizedWork: { clearCaches(); }
S>> case justDoIt: { doWork(); }
S>>}
S>>
ARK> Жуть. Goto в худшем виде.
Аргументы?
Как по мне, так тут всё чётко понятно как код исполняться будет. goto в этом отношении даёт возможность выстрелить себе в ногу, а switch нет
ARK>Вообще, конструкция switch в том виде, в каком она есть в С/C++,
Он такой везде
Здравствуйте, Sheridan, Вы писали:
S>>>switch полезен тем, что можно писать так, что код сможет выполняться не полностью. Например каттотак ARK>> Жуть. Goto в худшем виде. S>Аргументы?
Точно такие же скачки сквозь разные ветки управления. Сишный оператор switch не является оператором структурного программирования.
Чтобы "код выполнялся не полностью", существуют функции.
S>Как по мне, так тут всё чётко понятно как код исполняться будет. goto в этом отношении даёт возможность выстрелить себе в ногу, а switch нет
Не дает? Ну-ну. В действительности здесь прямо-таки раздолье для стрельбы по ногам. Позже постараюсь нарыть ссылку про ошибку в маршрутизаторе, написанном на С, из-за пропущенного break в свитче, приведшую к параличу линии связи. Сейчас не могу вспомнить, где читал.
ARK>>Вообще, конструкция switch в том виде, в каком она есть в С/C++, S>Он такой везде
Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков).
Здравствуйте, AlexRK, Вы писали:
S>>Аргументы? ARK>Точно такие же скачки сквозь разные ветки управления. Сишный оператор switch не является оператором структурного программирования.
Нет. При отсутствии break он будет выполняться строго сверху вниз, начиная от сработавшего case.
ARK>Чтобы "код выполнялся не полностью", существуют функции.
Ну да, вместо читаемого кода плодить кучу функций и оборачивать всё if'ами. Годный подход, ага.
S>>Как по мне, так тут всё чётко понятно как код исполняться будет. goto в этом отношении даёт возможность выстрелить себе в ногу, а switch нет ARK>Не дает? Ну-ну. В действительности здесь прямо-таки раздолье для стрельбы по ногам. Позже постараюсь нарыть ссылку про ошибку в маршрутизаторе, написанном на С, из-за пропущенного break в свитче, приведшую к параличу линии связи. Сейчас не могу вспомнить, где читал.
if(val=15) {}
switch в данном случае не при чём. Надо быть просто внимательным.
ARK>>>Вообще, конструкция switch в том виде, в каком она есть в С/C++, S>>Он такой везде ARK>Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков).
Примеры?
S>>>>switch полезен тем, что можно писать так, что код сможет выполняться не полностью. Например каттотак ARK>>> Жуть. Goto в худшем виде. S>>Аргументы? ARK>Точно такие же скачки сквозь разные ветки управления. Сишный оператор switch не является оператором структурного программирования. ARK>Чтобы "код выполнялся не полностью", существуют функции.
А чтобы работать как if существует if
S>>Как по мне, так тут всё чётко понятно как код исполняться будет. goto в этом отношении даёт возможность выстрелить себе в ногу, а switch нет ARK>Не дает? Ну-ну. В действительности здесь прямо-таки раздолье для стрельбы по ногам. Позже постараюсь нарыть ссылку про ошибку в маршрутизаторе, написанном на С, из-за пропущенного break в свитче, приведшую к параличу линии связи. Сейчас не могу вспомнить, где читал.
goto вполне безобиден в некоторых редких случаях, по сути эквивалентных try..finally, goto реализованный в switch'е — это как раз формальные рамки, ограничивающие возможность его применения только этими случаями. Альтернативный вариант — функция с множеством return'ов, как вы написали выше, но во многих случаях это слишком долго печатать, и программисты начинают порождать гораздо более вычурные, но локальные конструкции. switch в этом плане разумный компромисс, единственный минус — новички, которые приходят из других ЯП в которых свич — это разновидность ифа — у них трещат шаблоны.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Sheridan, Вы писали:
S>>>Аргументы? ARK>>Точно такие же скачки сквозь разные ветки управления. Сишный оператор switch не является оператором структурного программирования. S>Нет. При отсутствии break он будет выполняться строго сверху вниз, начиная от сработавшего case.
Строго вниз, строго вверх, нестрого назад — не имеет значения. Это разные ветки управления.
ARK>>Чтобы "код выполнялся не полностью", существуют функции. S>Ну да, вместо читаемого кода плодить кучу функций и оборачивать всё if'ами. Годный подход, ага.
Какую кучу функций? Функций должно быть столько, сколько надо.
Вместо вашего монстра код должен быть таким:
S>switch в данном случае не при чём. Надо быть просто внимательным.
Абсолютно все языковые конструкции — это об удобстве и внимательности. Некоторые удобны, некоторые нет. А некоторые просто уродливы, как сишный switch.
ARK>>>>Вообще, конструкция switch в том виде, в каком она есть в С/C++, S>>>Он такой везде ARK>>Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков). S>Примеры?
C#, Go, Ruby, Pascal, Ada, Eiffel...
UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором.
Здравствуйте, ononim, Вы писали:
O>goto вполне безобиден в некоторых редких случаях, по сути эквивалентных try..finally, goto реализованный в switch'е — это как раз формальные рамки, ограничивающие возможность его применения только этими случаями. Альтернативный вариант — функция с множеством return'ов, как вы написали выше, но во многих случаях это слишком долго печатать, и программисты начинают порождать гораздо более вычурные, но локальные конструкции. switch в этом плане разумный компромисс, единственный минус — новички, которые приходят из других ЯП в которых свич — это разновидность ифа — у них трещат шаблоны.
Сишный switch не вписывается в структурное программирование. На мой взгляд, одно это уже означает, что конструкция слегка "попахивает".
Ну и, конечно, возникает вопрос, какое поведение по умолчанию считать более ожидаемым — выход или переход на следующую ветку? Какой подход соответствует принципу наименьшего удивления? Некоторые люди считают, что первый (я в их числе). Создатели Ц решили, что второй.
Здравствуйте, T4r4sB, Вы писали:
S>>switch в данном случае не при чём. Надо быть просто внимательным. TB>Убивает такой подход. TB>Езда на лошади стоя тут ни при чём. Надо лишь не падать вперёд, назад, влево и вправо.
Убивает как раз подход "я не хочу ничего думать, я не хочу учиться, я не хочу быть внимательным, дайте мне такую штуку, чтобы вместо меня работала".
Здравствуйте, Sheridan, Вы писали:
S>Убивает как раз подход "я не хочу ничего думать, я не хочу учиться, я не хочу быть внимательным, дайте мне такую штуку, чтобы вместо меня работала".
Понятно, что без труда не выловишь и рыбку из пруда. Но в то же время, не стоит оправдывать совершенно идиотские недоработки, которые усложняют людям жизнь, не давая взамен никаких реальных преимуществ. Вот создали людям на пустом месте граблеопасное место, в котором надо быть внимательным. У человека ресурс внимания ограничен вообще-то, быть внимательным всё время — невозможно.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, AlexRK, Вы писали:
S>>>>Аргументы? ARK>>>Точно такие же скачки сквозь разные ветки управления. Сишный оператор switch не является оператором структурного программирования. S>>Нет. При отсутствии break он будет выполняться строго сверху вниз, начиная от сработавшего case. ARK>Строго вниз, строго вверх, нестрого назад — не имеет значения. Это разные ветки управления.
С этого места поподробнее: с какого времени порядок следования инструкций перестал иметь значение?
ARK>>>Чтобы "код выполнялся не полностью", существуют функции. S>>Ну да, вместо читаемого кода плодить кучу функций и оборачивать всё if'ами. Годный подход, ага. ARK>Какую кучу функций? Функций должно быть столько, сколько надо. ARK>Вместо вашего монстра код должен быть таким: ARK>
Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно?
Неужели вариант со свичем НАСТОЛЬКО хуже?
switch(getFlag())
{
case doFullWork: { checkLastWork(); clearTemp(); }
case doOptimizedWork: { clearCaches(); }
case justDoIt: { doWork(); }
}
Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем?
Ты случаем не споришь только ради спора?
S>>switch в данном случае не при чём. Надо быть просто внимательным. ARK>Абсолютно все языковые конструкции — это об удобстве и внимательности. Некоторые удобны, некоторые нет. А некоторые просто уродливы, как сишный switch.
он такой везде.
ARK>UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором.
Проверил? Да ладно? о0
Я вот действительно проверил: http://www.sergos.ru/player/js.html
ARK>>>Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков). S>>Примеры? ARK>C#, Go, Ruby, Pascal, Ada, Eiffel...
Точно так же проверял, как и жабаскрипт?
Здравствуйте, T4r4sB, Вы писали:
S>>Убивает как раз подход "я не хочу ничего думать, я не хочу учиться, я не хочу быть внимательным, дайте мне такую штуку, чтобы вместо меня работала". TB>Понятно, что без труда не выловишь и рыбку из пруда. Но в то же время, не стоит оправдывать совершенно идиотские недоработки...
Это НЕ недоработки, друг мой. Такое поведение заложено в свитч изначально. И оно, наравне с if, позволяет гибко управлять обработкой условий.
Здравствуйте, T4r4sB, Вы писали:
TB>Но в то же время, не стоит оправдывать совершенно идиотские недоработки, которые усложняют людям жизнь, не давая взамен никаких реальных преимуществ.
Здравствуйте, Sheridan, Вы писали:
ARK>>Строго вниз, строго вверх, нестрого назад — не имеет значения. Это разные ветки управления. S>С этого места поподробнее: с какого времени порядок следования инструкций перестал иметь значение?
Секунду, причем тут порядок следования инструкций?
S>А чего это забываем, что эти функции вызывать, обернув if'ами?
С того, что их не надо оборачивать if'ами. В изначальном коде про if'ы ничего не было. Мой вариант полностью эквивалентен вашему первому варианту.
S>Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно?
Я использую switch, когда надо. Но всегда без переходов в соседние ветки.
S>Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем?
Флаги это вообще зло. И если мы "добавляем еще три флага", то это повод задуматься о рефакторинге говнокода.
Кстати, а если мы вдруг заходим добавить в DoFullWork в самом конце еще Print (но не в doOptimizedWork и не в justDoIt)?
ARK>>UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором. S>Проверил? Да ладно? о0 S>Я вот действительно проверил
И? Результат проверки чем-то отличается?
ARK>>>>Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков). S>>>Примеры? ARK>>C#, Go, Ruby, Pascal, Ada, Eiffel... S>Точно так же проверял, как и жабаскрипт?
Здравствуйте, Sheridan, Вы писали:
S>Это НЕ недоработки, друг мой. Такое поведение заложено в свитч изначально. И оно, наравне с if, позволяет гибко управлять обработкой условий.
Разве не очевидно, что можно придумать куда менее травмоопасные способы добиться той же или даже большей гибкости?
Зачем такие грабли жирные повесили? Ради чего? Только по скудоумию двух кульных какир из 70го года.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте