do while используется в ситуациях, когда нужно, чтобы тело цикла отработало хотя бы один раз. Например, нужно сделать что-то, а если не получилось - повторить. И я, как человек регулярно использующий эту конструкцию, в очередной раз выражаю недоумение по поводу т.н. IT-юмора - у меня складывается впечатление, что пытаются шутить люди, знакомые с программированием только по школьным урокам.
29.03.2019, 18:27
я твой антагонист
Теперь деритесь до смерти.
Циклы вообще для лохов. Хвостовая рекурсия рулит. =Ъ
Ну, конкретное мнение зависит от источника, хотя, в принципе, почти все, хоть и не гонят пинками так же как goto, все же пренебрегают do while. "Можно, но лучше не надо" - общий вердикт.
Боязнь пользоваться do-while - она примерно там же, где и боязнь goto. В языках без сборки мусора без goto писать неприятно, потому что не ясно, как централизованно освобождать ресурсы по выходу из функции. Или прерывать циклы энного уровня вложенности - можно флагами, но goto удобнее. Его не добавляют в некоторые языки исключительно из-за того, что дурачки потом пишут на них логику. Мне кажется, это в корне неверный подход.
Скажем так - есть крайне ограниченный набор ситуаций в которых goto оправданно, в основном это встречается в случаях, когда надо написать код, быстро и эффективно обрабатывающий ошибки (типа ОС). В стандартном пользовательском приложении использование goto обычно тяжело оправдать. do-while может быть полезен, но нужно четко понимать: зачем он нужен. В противном случае легко багов навводить.
ИМХО, goto чаще всего применяется как раз в языках без сборки мусора, а в особенности, в Си. Это очень распространенный случай, когда ты выделяешь какие-то буферы, открываешь файлы или иные ресурсы, в конце должен все закрыть. Но у тебя куча проверок на успешность операций, в случае фейла goto на очистку. В С++ этого можно избежать, обернув ресурсы в классы и воспользовавшись RAII.
Тут, конечно, ебаные эксепшены, но можно и без них при большом желании, например, написать свой враппер над старым добрым маллоком.
Тут, конечно, ебаные эксепшены, но можно и без них при большом желании, например, написать свой враппер над старым добрым маллоком.
Программирование - это целый мир, и есть в нём разные закоулки. Есть тут и мощные системы на джаве, построенные по всем канонам оо-проектирования, есть и перфомансный низкоуровневый код, где допускается больше говнокода в угоду быстродействию.
Лично я чаще использую for/foreach/map/filter, чем do-while, и полностью согласен с картинкой.
Лично я чаще использую for/foreach/map/filter, чем do-while, и полностью согласен с картинкой.
его не впустили
Он еще хуже чем do while
В Swift можно сделать такую забавную конструкцию
for case let object as SomethingProtocol in objects { }
или
for object in objects where object is SomethingProtocol { }
Очень удобно когда надо пройтись по фильтрованному массиву без сдвига индексов или предварительной фильтрации
for case let object as SomethingProtocol in objects { }
или
for object in objects where object is SomethingProtocol { }
Очень удобно когда надо пройтись по фильтрованному массиву без сдвига индексов или предварительной фильтрации
Как мне кажется, фильтрация в циклах - какая-то муть. А её ещё в C++ 17 или 20 вводят.
Суть в том, что так с отфильтрованной коллекцией ничего нельзя сделать, кроме как пройтись по ней здесь и сейчас. Сохранить в переменную? Нет. Передать в функцию? Тоже нет. Второй раз пройти? Нет, надо снова писать такой же цикл!
Гораздо удобнее подход с filter в функциональном программировании или с generator expression in python. В этих случаях отфильтрованная коллекцию можно переиспользовать и/или сохранять в переменную/передавать как аргумент.
Суть в том, что так с отфильтрованной коллекцией ничего нельзя сделать, кроме как пройтись по ней здесь и сейчас. Сохранить в переменную? Нет. Передать в функцию? Тоже нет. Второй раз пройти? Нет, надо снова писать такой же цикл!
Гораздо удобнее подход с filter в функциональном программировании или с generator expression in python. В этих случаях отфильтрованная коллекцию можно переиспользовать и/или сохранять в переменную/передавать как аргумент.
Ну в Swift можно вызвать метод filter для коллекции и в функциональном стиле отфильтровать а потом записать в переменную. Тут другой кейс использования. Допустим у тебя есть коллекция всех UIView и тебе нужно стереть текст из всех UIViewLabel (подкласс UIView) в стандартном подходе ты делаешь каст к нужному типу внутри цикла по всем элементам. Ну или сначала фильтруешь коллекцию по типу элементов а потом снова пробегаешься по всей коллекции. Это не круто. Решение пробегать только по необходимым элементам не удаляя остальные гораздо более гибкое и красивое.
В любом случае Swift это опенсорс проект (на данный момент последняя версия Swift 5) и у любой фичи языка есть четкое обоснование и одобрение сообщества. Не правильно говорить что это какая-то муть.
В любом случае Swift это опенсорс проект (на данный момент последняя версия Swift 5) и у любой фичи языка есть четкое обоснование и одобрение сообщества. Не правильно говорить что это какая-то муть.
А, тут ещё и динамика замешана. Интересно. Впрочем, не так важно, по чему фильтровать.
Такая конструкция красивее простого цикла, хотя менее гибкая, чем filter+map и их аналоги на итераторах.
Результат filter можно засунуть в любое место, куда можно было засунуть массив, даже в тот же цикл с фильтрацией. Код становится более однородным, для разных обходов и преобразований коллекции используются одни и те же инструменты.
Понадобилось наложить фильтр на фильтр - filter удобнее цикла. Понадобилось отложить выполнение: сначала вычленить нужные элементы, а потом где-то стереть из них текст - filter удобнее цикла. Понадобилось применить стандартный алгоритм (например, в C++, что-нибудь из алгоритмов из STL) - filter удобнее цикла, для цикла надо реализовывать алгоритм ещё раз.
Хитрый цикл усложняет язык, а filter пишется в рамках существующего языка, в зависимости от задачи можно реализовать версию с копированием в новый список или, версию с итератором, чтобы O(1) по памяти. Если написать правильный bidirectional итератор, можно с помощью std::sort отсортировать отфильтрованные элементы прямо на их местах в коллекции. Написать несколько строк кода на обычном языке для конкретного проекта - гораздо проще и спокойнее, чем ждать месяцы заседаний комитетов, утверждений фичи, добавление в компиляторы, поддержка фичи долгие годы (из-за чего обновлённый язык выглядит уродливо), невозможность простого удаления фичи, если ей воспользовались в куче старого кода.
Чёткое обоснование можно к любой фиче написать. Формально восьми операций языка brainfuck хватает для написания любых вычислительных программ, всё остальное - мнения и оценки стоимости конкретных проектов с конкретными исполнителями :)
Сообществу не стоит доверять. Сообщества обычно плодят усреднённые компромиссные решения, рассчитанные на потребителя с усреднёнными показателями (которого не существует). А главное - полёт фантазии сообщества ограничен привычками, уже реализованными фичами и представлениями по здравом смысле.
Такая конструкция красивее простого цикла, хотя менее гибкая, чем filter+map и их аналоги на итераторах.
Результат filter можно засунуть в любое место, куда можно было засунуть массив, даже в тот же цикл с фильтрацией. Код становится более однородным, для разных обходов и преобразований коллекции используются одни и те же инструменты.
Понадобилось наложить фильтр на фильтр - filter удобнее цикла. Понадобилось отложить выполнение: сначала вычленить нужные элементы, а потом где-то стереть из них текст - filter удобнее цикла. Понадобилось применить стандартный алгоритм (например, в C++, что-нибудь из алгоритмов из STL) - filter удобнее цикла, для цикла надо реализовывать алгоритм ещё раз.
Хитрый цикл усложняет язык, а filter пишется в рамках существующего языка, в зависимости от задачи можно реализовать версию с копированием в новый список или, версию с итератором, чтобы O(1) по памяти. Если написать правильный bidirectional итератор, можно с помощью std::sort отсортировать отфильтрованные элементы прямо на их местах в коллекции. Написать несколько строк кода на обычном языке для конкретного проекта - гораздо проще и спокойнее, чем ждать месяцы заседаний комитетов, утверждений фичи, добавление в компиляторы, поддержка фичи долгие годы (из-за чего обновлённый язык выглядит уродливо), невозможность простого удаления фичи, если ей воспользовались в куче старого кода.
Чёткое обоснование можно к любой фиче написать. Формально восьми операций языка brainfuck хватает для написания любых вычислительных программ, всё остальное - мнения и оценки стоимости конкретных проектов с конкретными исполнителями :)
Сообществу не стоит доверять. Сообщества обычно плодят усреднённые компромиссные решения, рассчитанные на потребителя с усреднёнными показателями (которого не существует). А главное - полёт фантазии сообщества ограничен привычками, уже реализованными фичами и представлениями по здравом смысле.
![class Joyreactor {
var array = ["one", "two", "three", "four", "five", "six"]
III Хочу вывести на экран слова из трех букв func printTriplesi) {
// 1
for word in array {
if word.count == 3 { print(word)
}
>
// 2
array.filter{ $0.count == 3 }.forEach{ print($0) }
// 3
for word in array](https://img2.joyreactor.cc/pics/comment/full/it-юмор-geek-3310910.png "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор")
Ты наверно перепутал, 2 - функциональный.
В третем это проход по массиву через for это конечно можно рассматривать как вызов функции для элементов массива, но этот вызов происходит для исходных элементов. Нет процесса фильтрации (создания отфильтрованного массива). Это довольно легко проверить на массиве большого размера.
В третем это проход по массиву через for это конечно можно рассматривать как вызов функции для элементов массива, но этот вызов происходит для исходных элементов. Нет процесса фильтрации (создания отфильтрованного массива). Это довольно легко проверить на массиве большого размера.
If
GOTO
GOTO
Чтобы написать коммент, необходимо залогиниться
