__>безусловно, но использовать более одного return — это моветон
Это многое объясняет Впрочем возможно для С это действительно не комильфо, но тут... та-да! на сцену на белом ишаке выезжает С++ с RAII наперевес
Как много веселых ребят, и все делают велосипед...
S>>Это НЕ недоработки, друг мой. Такое поведение заложено в свитч изначально. И оно, наравне с if, позволяет гибко управлять обработкой условий. TB>Разве не очевидно, что можно придумать куда менее травмоопасные способы добиться той же или даже большей гибкости? TB>Зачем такие грабли жирные повесили? Ради чего? Только по скудоумию двух кульных какир из 70го года.
Ни разу не помню чтоб напарывался на эти грабли. То есть если и напарывался — то совершенно несеръезно. В тоже время пользуюсь этой гибкостью регулярно. ИМХО это примерно грабли такого же рода как "ух ты, а оказывается поинтер после free не становится равным нулю"
Как много веселых ребят, и все делают велосипед...
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Sheridan, Вы писали:
ARK>>>Строго вниз, строго вверх, нестрого назад — не имеет значения. Это разные ветки управления. S>>С этого места поподробнее: с какого времени порядок следования инструкций перестал иметь значение? ARK>Секунду, причем тут порядок следования инструкций?
Строго вниз, строго вверх, нестрого назад — не имеет значения.
S>>А чего это забываем, что эти функции вызывать, обернув if'ами? ARK>С того, что их не надо оборачивать if'ами. В изначальном коде про if'ы ничего не было. Мой вариант полностью эквивалентен вашему первому варианту.
Дааа? switch у меня обрабатывает условие, а не if. Или ты не в курсе, что свич по условию работает?
S>>Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно? ARK>Я использую switch, когда надо. Но всегда без переходов в соседние ветки.
В подавляющем большинстве случаев его так и используют
S>>Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем? ARK>Флаги это вообще зло. И если мы "добавляем еще три флага", то это повод задуматься о рефакторинге говнокода.
Да и код вообще зло. Лучше на канары, правда?
ARK>Кстати, а если мы вдруг заходим добавить в DoFullWork в самом конце еще Print (но не в doOptimizedWork и не в justDoIt)?
Про подобные варианты разворачивания событий я писал уже давно
Я в курсе, что когда возразить нечего — один из вариантов попробовать положить соперника на лопатки — усложнять задачу до тех пор, пока собеседник не скажет "В этом случае да, мой инструмент не подходит". Обычно после этого инструмент соперника объявляется гавном.
ARK>>>UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором. S>>Проверил? Да ладно? о0 S>>Я вот действительно проверил ARK>И? Результат проверки чем-то отличается?
По поведению от c\c++? Нет. О чём я тебе и говорил
ARK>>>>>Да нет, такого нет больше нигде (ну, лично я не помню других подобных языков). S>>>>Примеры? ARK>>>C#, Go, Ruby, Pascal, Ada, Eiffel... S>>Точно так же проверял, как и жабаскрипт? ARK>По сути есть что сказать?
По сути я только и говорю. А у тебя?
Здравствуйте, T4r4sB, Вы писали:
S>>Это НЕ недоработки, друг мой. Такое поведение заложено в свитч изначально. И оно, наравне с if, позволяет гибко управлять обработкой условий. TB>Разве не очевидно, что можно придумать куда менее травмоопасные способы добиться той же или даже большей гибкости? TB>Зачем такие грабли жирные повесили? Ради чего? Только по скудоумию двух кульных какир из 70го года.
Я не могу понять что в switch не так, чем он травмоопасен? Или ты про ситуацию "студент недоучка спотыкается об switch и ломает ногу каждые три часа"? Ради этого надо вонь поднимать и switch ругать? А может всётаки студенту вторую ногу сломать, чтобы выучил наконец язык, на котором собрался писать?
А когда "студент" споткнется об
if(val=16) {...}
, тогда нужно еще и обработку условий коричнево помазать, так что ли?
Здравствуйте, Sheridan, Вы писали:
ARK>>>>Строго вниз, строго вверх, нестрого назад — не имеет значения. Это разные ветки управления. S>>>С этого места поподробнее: с какого времени порядок следования инструкций перестал иметь значение? ARK>>Секунду, причем тут порядок следования инструкций? S>
S>Строго вниз, строго вверх, нестрого назад — не имеет значения.
Ну вы представляете, что такое структурное программирование?
Понимаете, что "порядок следования инструкций" и "направление безусловного перехода" — это вещи не связанные?
S>>>А чего это забываем, что эти функции вызывать, обернув if'ами? ARK>>С того, что их не надо оборачивать if'ами. В изначальном коде про if'ы ничего не было. Мой вариант полностью эквивалентен вашему первому варианту. S>Дааа? switch у меня обрабатывает условие, а не if. Или ты не в курсе, что свич по условию работает?
Причем тут "switch у меня обрабатывает условие"?
У вас нет _вызова_ функции и в вашем коде нет ничего, что указывало бы на то, откуда этот флаг берется.
S>>>Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно? ARK>>Я использую switch, когда надо. Но всегда без переходов в соседние ветки. S>В подавляющем большинстве случаев его так и используют
Нет, в подавляющем большинстве случаев его так не используют.
S>>>Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем? ARK>>Флаги это вообще зло. И если мы "добавляем еще три флага", то это повод задуматься о рефакторинге говнокода. S>Да и код вообще зло. Лучше на канары, правда?
Демагогия. Могу только лишь еще раз сказать, что флаги — это зло.
ARK>>Кстати, а если мы вдруг заходим добавить в DoFullWork в самом конце еще Print (но не в doOptimizedWork и не в justDoIt)? S>Про подобные варианты разворачивания событий я писал уже давно
S>Я в курсе, что когда возразить нечего — один из вариантов попробовать положить соперника на лопатки — усложнять задачу до тех пор, пока собеседник не скажет "В этом случае да, мой инструмент не подходит". Обычно после этого инструмент соперника объявляется гавном.
Да-да. А кто начал усложнять про "добавляем еще три флага"? "Не лучше ль, кума, на себя оборотиться?" (с)
ARK>>>>UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором. S>>>Проверил? Да ладно? о0 S>>>Я вот действительно проверил ARK>>И? Результат проверки чем-то отличается? S>По поведению от c\c++? Нет. О чём я тебе и говорил
Так вот, языков таких мне известно 4 штуки. Языков с другим поведением — гораздо больше.
ARK>>По сути есть что сказать? S>По сути я только и говорю. А у тебя?
По сути: C#, Go, Ruby, Pascal, Ada, Eiffel — обладают семантикой, отличной от C/C++.
Здравствуйте, _hum_, Вы писали:
X>>А можно реальный пример, где Вы решили сэкономить в угоду читабельности, убрав пару break. __>да в любом коде лишняя торчащая и затеняющая основное значение конструкция — это вред. а тут этот break: __>
__>swicth(a)
__>{
__>case 1: x = 1001; break;
__>case 2: x = 4002; break;
__>};
__>swicth(a)
__>{
__>case 1: x = 1001;
__>case 2: x = 4002;
__>};
__>
__>(особенно, когда кейсов много, и ошибиться в них ни в коем случае нельзя)
Друг мой, изучай инструмент, с которым работаешь, мой тебе совет.
И тогда у тебя не будет случаться таких факапов, как случился в твоём проекте с switch. Надеюсь, ты успел понять где у тебя ошибка перед сдачей релиза, а не после...
S>>>Это НЕ недоработки, друг мой. Такое поведение заложено в свитч изначально. И оно, наравне с if, позволяет гибко управлять обработкой условий. TB>>Разве не очевидно, что можно придумать куда менее травмоопасные способы добиться той же или даже большей гибкости? TB>>Зачем такие грабли жирные повесили? Ради чего? Только по скудоумию двух кульных какир из 70го года. S>Я не могу понять что в switch не так, чем он травмоопасен?
Это холивар "либерализм рулит" vs "а вот при Сталине case-ы не проваливались бы"
Как много веселых ребят, и все делают велосипед...
S>>Строго вниз, строго вверх, нестрого назад — не имеет значения.
ARK>Ну вы представляете, что такое структурное программирование? ARK>Понимаете, что "порядок следования инструкций" и "направление безусловного перехода" — это вещи не связанные?
Я — да. А ты понимаешь, что код не следует загромождать лишними сущностями, если можно написать лакончно, это будет читабельно и будет работать?
S>>Дааа? switch у меня обрабатывает условие, а не if. Или ты не в курсе, что свич по условию работает? ARK>Причем тут "switch у меня обрабатывает условие"? ARK>У вас нет _вызова_ функции и в вашем коде нет ничего, что указывало бы на то, откуда этот флаг берется.
То есть мне нужно создать новый проект, написать кучу кода, обложить тестами и выложить на гитхаб дабы было понятно откуда в переменной появляется значение? Или мы всетаки опустим незначащие сущности?
S>>>>Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно? ARK>>>Я использую switch, когда надо. Но всегда без переходов в соседние ветки. S>>В подавляющем большинстве случаев его так и используют ARK>Нет, в подавляющем большинстве случаев его так не используют.
Погоди. Давай расставим точки везде. Я соглашаюсь с тобой, что в подавляющем большинстве случаев везде в case'ах присутствует break, что делает невозможным переход в низлежайший case.
А ты ВНЕЗАПНО со мной не соглашаешься.
Спор ради спора?
S>>>>Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем? ARK>>>Флаги это вообще зло. И если мы "добавляем еще три флага", то это повод задуматься о рефакторинге говнокода. S>>Да и код вообще зло. Лучше на канары, правда? ARK>Демагогия. Могу только лишь еще раз сказать, что флаги — это зло.
И переменные — зло. И функции — зло. Классы тоже зло... Строго говоря, ООП целиком зло. А по чесноку — программирование зло из зол. Лучше на канары. Да?
ARK>>>Кстати, а если мы вдруг заходим добавить в DoFullWork в самом конце еще Print (но не в doOptimizedWork и не в justDoIt)? S>>Про подобные варианты разворачивания событий я писал уже давно
S>>Я в курсе, что когда возразить нечего — один из вариантов попробовать положить соперника на лопатки — усложнять задачу до тех пор, пока собеседник не скажет "В этом случае да, мой инструмент не подходит". Обычно после этого инструмент соперника объявляется гавном.
ARK>Да-да. А кто начал усложнять про "добавляем еще три флага"? "Не лучше ль, кума, на себя оборотиться?" (с)
У меня нет цели доказать что switch истина в последней инстанции и все обязаны его применять. Я всего лишь пытаюсь рассказать о том, что его семантика имеет смысл и что есть варианты использовать эту семантику на пользу себе. А тут же в ветках, в том числе и у тебя, просматривается "свитч — гавно, его клепали неучи и вообще его использовать — зло как и goto"
ARK>>>>>UPD. Сейчас посмотрел, в Java и JavaScript break необязателен, хотя мне казалось, что был обязателен. Теперь я знаю 4 языка с таким оператором. S>>>>Проверил? Да ладно? о0 S>>>>Я вот действительно проверил ARK>>>И? Результат проверки чем-то отличается? S>>По поведению от c\c++? Нет. О чём я тебе и говорил ARK>Так вот, языков таких мне известно 4 штуки. Языков с другим поведением — гораздо больше. ARK>По сути: C#, Go, Ruby, Pascal, Ada, Eiffel — обладают семантикой, отличной от C/C++.
Примеры, камрад, примеры. Наговнокодь, как я, немножко кода по типу того что я показал. А лучше 1-в-1. И покажи результат.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
S>>>>>Аргументы?
S>А чего это забываем, что эти функции вызывать, обернув if'ами? Давай я за тебя S>
S>Неужели ты будешь жертвовать читабельностью кода, будешь запутывать код только ради того чтобы свитч не применять? Да ладно? S>Неужели вариант со свичем НАСТОЛЬКО хуже? S>
S>switch(getFlag())
S>{
S> case doFullWork: { checkLastWork(); clearTemp(); }
S> case doOptimizedWork: { clearCaches(); }
S> case justDoIt: { doWork(); }
S>}
S>
S>Более того, добавляем еще три флага и рисуем еще три функции? Еще больше запутываем? S>Ты случаем не споришь только ради спора?
Ваш код ужасен для чтения и сопровождения (в нем логика работы завязана на goto-style, из-за чего фрагменты кода становятся сильно связанными между собою). И не надо плодить лишних процедур, достаточно поступить следующим образом:
Теперь представьте, что у вас добавился флаг "doSpecialWork", предполагающий выполнение полной работы, но с пропуском этапа очистки кэша. В каком варианте его легче будет реализовать?
Здравствуйте, _hum_, Вы писали:
__>Ваш код ужасен для чтения и сопровождения (в нем логика работы завязана на goto-style, из-за чего фрагменты кода становятся сильно связанными между собою). И не надо плодить лишних процедур, достаточно поступить следующим образом:
Да я уже понял. Наилучшее ружжо — ваше. Остальные — брёвна.
__>Теперь представьте, что у вас добавился флаг "doSpecialWork", предполагающий выполнение полной работы, но с пропуском этапа очистки кэша. В каком варианте его легче будет реализовать?
А теперь представьте, что спор не о флагах, а о возможностях switch. Ой, погодите, а ведь именно так оно и есть о0
Здравствуйте, Sheridan, Вы писали:
ARK>>Ну вы представляете, что такое структурное программирование? ARK>>Понимаете, что "порядок следования инструкций" и "направление безусловного перехода" — это вещи не связанные? S>Я — да. А ты понимаешь, что код не следует загромождать лишними сущностями, если можно написать лакончно, это будет читабельно и будет работать?
То, что сегодня лаконично и читабельно, завтра окажется говнокодом.
Для того, чтобы формализовать правила, что лаконично, а что нет, изобрели структурное программирование. Сишный свитч нарушает правила структурного программирования.
S>То есть мне нужно создать новый проект, написать кучу кода, обложить тестами и выложить на гитхаб дабы было понятно откуда в переменной появляется значение? Или мы всетаки опустим незначащие сущности?
Мой код _полностью_ эквивалентен вашему первоначальному варианту. Этот факт вам понятен?
Если выбор осуществляется именно флагом, то да, можно и нужно использовать и свитч. В сочетании с набором функций. Fallthrough при этом не нужен.
S>Погоди. Давай расставим точки везде. Я соглашаюсь с тобой, что в подавляющем большинстве случаев везде в case'ах присутствует break, что делает невозможным переход в низлежайший case. S>А ты ВНЕЗАПНО со мной не соглашаешься.
А, да. Тут моя ошибка, прошу прощения. Я неправильно понял.
S>У меня нет цели доказать что switch истина в последней инстанции и все обязаны его применять. Я всего лишь пытаюсь рассказать о том, что его семантика имеет смысл и что есть варианты использовать эту семантику на пользу себе. А тут же в ветках, в том числе и у тебя, просматривается "свитч — гавно, его клепали неучи и вообще его использовать — зло как и goto"
Ну, смысл можно найти во всем. Всегда найдется некоторый контекст, в котором некоторое средство будет удобно и адекватно.
А здесь говорится, что выбор создателей С был, по мнению некоторых людей, не вполне удачен. Для языка общего назначения, которым С и стал по факту.
S>Примеры, камрад, примеры. Наговнокодь, как я, немножко кода по типу того что я показал. А лучше 1-в-1. И покажи результат.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, _hum_, Вы писали:
__>>Теперь представьте, что у вас добавился флаг "doSpecialWork", предполагающий выполнение полной работы, но с пропуском этапа очистки кэша. В каком варианте его легче будет реализовать? S>А теперь представьте, что спор не о флагах, а о возможностях switch. Ой, погодите, а ведь именно так оно и есть о0
вопрос не о возможностях switch, а о его семантике — насколько она удачна, чтобы писать легко читаемый и модифицируемый код.
вы привели пример, который, по-вашему, хорошо иллюстрирует достоинства свитча. я вам показал, что такой код не обладает модифицируемостью, и в то же время не намного сокращает объем кода (в отличие от if-подхода). что еще?
Здравствуйте, Sheridan, Вы писали:
ARK>>Вообще, конструкция switch в том виде, в каком она есть в С/C++, S>Он такой везде
Нет.
В D каждый case должен оканчиваться или break или "goto case" (явное указание провалиться дальше). То есть случайно пропустить break не получится. Ну и там есть некоторое количество специальных случаев когда break не требуется, например, если выбрасывается исключение.
В Swift и Go есть специальное ключевое слово fallthrough, а break используется по умолчанию и явно писать его не требуется.
В C#, опять же, неявного fallthrough нет, зато есть goto на любой case.
Некоторые языки (например, Rust) обходятся без switch как такового и вместе этого предлагают паттерн матчинг. Естественно, без fallthrough.
В современных решениях польза от применения метода Даффа сомнительна. Метод затрудняет работу оптимизирующих компиляторов и предсказателя переходов.[1] Например, после удаления кода Даффа из XFree86 версии 4.0, бинарные файлы уменьшились примерно на 0,5 МБ, и сервер стал загружаться быстрее.
Да и разве тут кто-то ратует за полный запрет такой возможности? Просто можно было бы ввести ключевое слово типа fallthrough для явного указания намерений.
Здравствуйте, AlexRK, Вы писали:
ARK>А, да. Тут моя ошибка, прошу прощения. Я неправильно понял.
ARK>Ну, смысл можно найти во всем. Всегда найдется некоторый контекст, в котором некоторое средство будет удобно и адекватно.
S>>Примеры, камрад, примеры. Наговнокодь, как я, немножко кода по типу того что я показал. А лучше 1-в-1. И покажи результат. ARK>Хорошо. Я сделаю это сегодня, чуть позже.
зы Сначала начал писать много текста, но потом дочитал до адекватных ответов и потёр все нафиг. Спасибо.
Здравствуйте, _hum_, Вы писали:
__>вопрос не о возможностях switch, а о его семантике — насколько она удачна, чтобы писать легко читаемый и модифицируемый код.
Ну есть свич и есть if. У нас есть выбор, это же хорошо!
__>вы привели пример, который, по-вашему, хорошо иллюстрирует достоинства свитча. я вам показал, что такой код не обладает модифицируемостью, и в то же время не намного сокращает объем кода (в отличие от if-подхода). что еще?
Естественно, на каждую хитрую ... найдется ... с винтом, это отрицать нельзя. Да и языки, в том числе и ц++, достаточно выразительные, чтобы одно и то же можно было сделать множеством способов.
Я всего лишь показал наглядный пример. Не больше, не меньше.
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, Sheridan, Вы писали:
ARK>>>Вообще, конструкция switch в том виде, в каком она есть в С/C++, S>>Он такой везде DE>Нет.
DE>В D каждый case должен оканчиваться или break или "goto case" (явное указание провалиться дальше). То есть случайно пропустить break не получится. Ну и там есть некоторое количество специальных случаев когда break не требуется, например, если выбрасывается исключение.
Тогда там switch не нужен, он становится if'ом при таком раскладе, но с другим синтаксисом и позволяет не писать города из if else.
DE>В Swift и Go есть специальное ключевое слово fallthrough, а break используется по умолчанию и явно писать его не требуется.
То есть просто зеркальное поведение от ц++, так? Левая и правая руки. Если так, то пример не показателен. В ц++ надо явно проставлять бряки, когда хочешь сработку только одного case, а тут наоборот, надо явно указать fallthrough если нужна сработка нескольких по порядку.
DE>Некоторые языки (например, Rust) обходятся без switch как такового и вместе этого предлагают паттерн матчинг. Естественно, без fallthrough.
Интересный язык. Буду чего нибудь писать в плане скриптов — попробую как нибудь.
Впрочем, ихний match хотя и мощный, но fallthrough действительно, похоже, нет и они этим показательно гордятся, гм.
Что ж. Я погорячился про "все". Пусть будет "многие"
