На фотке индус, он не использует циклы
Он пишет
$sum=1+2+3+4+5+.......+99997+99998+99999;
echo $sum;
Это не важно. Важно что запись длинная и кринжовая. Индусы - это негры программисты, которые получают деньги за количество строк или количество символов в коде. И чтобы увеличить длину кода - делают такой хуевый код. Я как-то видел код, в котором число пи заново высчитывали в процессе инициализации через квадратуру круга.
Это как навык катания на чем-либо. Если один раз увидеть индусский код - всегда его отличишь среди другого кода.
З.ы. к IT никакого отношения не имею, но примерно понимаю
Господи благослови редактирование комментариев.
Когда жму кнопку "отправить", приходит идея как сказать лучше
foreach бесит немного когда пытаешься дебажить, или стэктрейс выдает первую строку, хотя упало где-то посередине.
Любой. В любом языке с foreach есть своя реализация стека и очереди. И если привести их к общему интерфейсу, то хрен ты угадаешь, в каком порядке тебе сейчас пойдут значения при обходе, в том же, в котором ты их туда клал или в противоположном.
Что значит "привести реализации стека и очереди к общему интерфейсу"? foreach в каждом языке где он имеется, уже, собственно, реализован, куда и к чему вы его будете приводить? Некоторые из реализаций гарантируют порядок обхода.
Это значит, дорогой мой профессионал, в случае шарпов, например, вот это: (IEnumerable)myStack и (IEnumerable)myQueue
Ну так а речь-то не об конкретном интерфейсе в конкретном языке, а о разнице в реализации в разных языках. Во-первых есть языки, где foreach не метода для интерфейса, а функция, тот же JS. Во-вторых в том же шарпе реализация IEnumerable для List'а гарантирует порядок. Сам интерфейс его чаще всего не гарантирует, это да.
не передергивайте, окей? в данной ветке кое-кто не понял что означает фраза "привести к общему интерфейсу". я пояснил. в случае шарпов, например, этот интерфейс реализуют все коллекции, если хотят быть перечисленными в foreah. и "привести" означает, что коллекции берутся как как объекты своих типов, а как объекты, реализующие IEnumerable, что, в свою очередь скрывает тип коллекции. в других языках есть полностью аналогичные механизмы, но я не статью на хабр пишу, чтобы их ту все перечислять. если знаете какой-то язык - понимаете о чем я.
Правильно не понял, потому что нельзя привести типы данных из разных языков к одному интерфейсу, это бред. Тем более что вы это сформулировали, ещё раз, "привести реализации стека и очереди". Реализации вообще ни к чему никуда не приводятся, ни в одном языке, приводятся типы, а точнее даже экземпляры типов, объекты. И статья на Хабре тут ни при чём - вы просто напутали с терминологией, да ещё и а контексте разных языков.
К чему вы мне начали объяснять работу перечисляемых типов в шарпе - я не понял. В разных языках это работает по разному, и не везде есть схожий механизм.
да это вы тут смешали все в одну кучу. в каждом языке есть реализация стека и очереди. если взять в каком-то языке местные реализации стека и очереди, это будут типы, ясен красен. реализация, если что, это как раз какой-то тип, реализующий некую логику. логика очереди и стека не зависит от языка, да? но каждый язык имеет собственную реализацию этих абстракций, иногда даже не по одной.
любой язык (окей, мой косяк, я всю дорогу имел в виду ооп языки) имеет механизмы абстрагирования. и я вел речь именно о том, чтобы абстрагировать два типа, реализующих логику очереди и стека, до абстракции уровня "это можно перечислить". в таком случае невозможно понять, в каком порядке будет перечисление, так как истинный тип скрыт за абстракцией.
Так сказал, будто в случае с for порядок гарантируется.
Итерирование - это не про порядок, а про обход. Какой будет порядок - зависит от много чего.
Ну и да, во многих языках есть структуры, которые foreach обходит по порядку. Тем не менее нельзя считать, что ты получишь тот порядок, который был, когда ты туда складывал, ибо мутабельность и многопоточность.
ибо мутабельность и многопоточность
В этом случае обходить вообще будет некорректно.
Либо мутабельность, либо блокировки)
Что за херню вы несете?
Покажите пример когда вы положите в List (мы про же про Шарп?) 1,2,3,4,а потом через foreach вы выведите 4,3,2,1. И при этом обращение через индекс будет выводить правильную последовательность.
мы про же про Шарп?
Даже в Шарпе я могу запилить свою собственную реализацию IEnumerable с блекджеком и шлюхами и будет вам какой угодно порядок, хоть рандомный каждый раз.
От List ожидается соблюдение порядка, так как он допускает обращение к элементу по его индексу. Dictionary и HashSet по умолчанию соблюдение порядка добавления элементов уже не гарантируют.
с чего бы речь шла о стандартных реализациях? так как мы обсуждаем мой коммент в этой ветке, я поясню: когда перед тобой IEnumerable ты хрен с два угадаешь в каком порядке сейчас перечисление будет. точно так же ты не в курсе, там за ним стандартная реализация или что-то кастомное, а может быть вообще цепочка LINQ методов.
при чем тут лист, але? он в шарпах вообще обертка над массивом. я сказал очередь и стек. и если так хотите, то вот код, который при одинаковой последовательности ввода даст разную последовательность вывода: https://pastebin.com/Y2fyeK6d
ну и так чисто по фану, пример когда я положил в List 1,2,3,4,а потом через foreach вы вывел 4,3,2,1. И при этом обращение через индекс будет выводить правильную последовательность. :D
foreach (var entry in ((IEnumerable<int>)new List<int> { 1, 2, 3, 4 }).Reverse())
Console.Write($"{entry} ");
чиво блять? Причём тут стек и очередь к foreach и почему вдруг я не могу знать, итерирую я стек или очередь?
потому что для итерирования не нужно знать конкретный тип. а не зная конкретного типа невозможно угадать в каком порядке будет перечисление: https://pastebin.com/Y2fyeK6d
там выше речь шла про гарантированность порядка обхода, в твоём примере он гарантирован структурой, которую ты итерируешь, а то, что ты забыл, что итерируешь к делу не относится.
давай я тебе накидаю енумератор в три строки, который значения по рандому выдавать будет, если тебе так хочется?
что значит, забыл? в реальном коде ты частенько и не знаешь, что ты итерируешь. перечисляемое и ладно. там может быть вообще никакой коллекции нет, за этим интерфейсом.
я больше скажу. foreach не только порядок не гарантирует, он не гарантирует, что значения вернутся все, не гарантирует, что при повторном итерировании значения будут в том же порядке, или хотя бы те же, не гарантирует даже, что повторное итерирование в принципе возможно. он вообще ничего не гарантирует
про какой язык говорить
так и в каком языке форыч гарантирует порядок? именно сам по себе оператор foreach?
и какую структуру итерировать
так в том и смысл, что порядок определяет не оператор, а структура. foreach - не структура
С какой стати? Единственное неудобство forEach - не видно индекс. А вообще сейчас почему-то все вместо for-ов по map-ам угорают и прочей функциональщине.
Может быть, map-reduce хорошо параллелятся, поэтому в современности на них налегают?
Ну и читается `let squares = numbers.map(x => x*x)` куда лучше чем что-то типа `for (int i = 0; i < numbers.length; i++) squares.push(numbers[i]*numbers[i])`
Приведи пример, когда тебе так уж нужен индекс обрабатываемого значения в коллекции, если у тебя и так есть само значение
Например, импорт юзеров из файла (с логинами и хэшами паролей). Если что-то пошло не так, кидаем экспепшн, но указывать sensitive data нехорошо, логично указать номер строки где произошла ошибка (и тут нам нужен индекс).
Это как сортировка набора данных: хочешь гарантированно - пиши order by
Гарантии определяются типом коллекции, которую мы собираемся обходить. Если порядок элементов задается натуральным образом, то обходить мы их будем по порядку.
Сюда можно подтянуть нюансы с параллельной обработкой коллекций, но это уже другая история.
ну, вот в крестах, например, оно компиляется в итератор и если мы итерируем вектор, например, то там вполне гарантированн порядок элементов
В разных языках по разному. К тому же сильно зависит от реализации того объекта, по которому идёт итерация.
for-each со слегка разным синтаксисом есть в C++, Java, Python, C# - везде это обход коллекции по порядку, определённому коллекцией. В каких это "разных языках" по-другому? Вася Пупкин - экспериментатор написал язык Mother Fucker, где по-другому, и с тех пор в разных языках по-разному?
В результате порядок обхода в "for-each" гарантируется быть таким, как его реализовал создатель контейнера. Согласитесь, есть большая разница с "не гарантируется".
Ну так это оно и есть, что порядок обхода коллекции может быть непредсказуем. Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции. А вот в каком порядке оно их выдаст - зависит от того, что там разработчик намудрил.
Эта ветка началась с вашего
foreach не гарантирует порядок обхода.
Это по-прежнему не так. for-each, как конструкция языка, гарантирует порядок обхода в соответствии с порядком, определённым коллекцией.
Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции
Неверно. Ни намёка на такую гарантию нет. Что, элемент "17" не может быть возвращён два раза при проходе по вектору?
порядок обхода коллекции может быть непредсказуем
Да, некоторые коллекции определены так, что порядок их обхода не определён. Но "порядок может быть непредсказуем для определённых коллекций" никак не транслируется в "foreach не гарантирует порядок обхода".
"Коллекция" вообще дугая сущность, нежели конструкция "for-each". Из неопределённости порядка для некоторых видов первой никак не следует неопределённость работы второй.
А вот в каком порядке оно их выдаст - зависит от того, что там разработчик намудрил.
Вам по не понятной причине кажется, что существование неупорядоченных коллекций настолько важно и всеобъемлюще, что оно должно обобщаться до "у коллекций нет гарантий упорядоченности". У большинства видов коллекций такая гарантия есть. Ну да, есть одна, у которой нет. Опять же, это не касается for-each.
Неверно. Ни намёка на такую гарантию нет. Что, элемент "17" не может быть возвращён два раза при проходе по вектору?
Я, наверное, чего-то не знаю?
Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции.
Нет такой гарантии. Ибо кольцевые буферы.
В C#, например, решарпер будет ворнинг об этом кидать при попытке итерации даже через простой IEnumerable.
Нет такой гарантии. Ибо кольцевые буферы.
Хм... Действительно. Ну вот в голову бы не пришло такое через foreach делать. К вопросу о.
Вам - не придет. А какой-нибудь коллега может заюзать высокоуровневый интерфейс (где в глубине подкапотного вы полагались на существование такой гарантии) и передав имплементацию кольцевого буфера потенциально получит бесконечный цикл (=
j - это всё... Написал по ошибке вместо j i во вложенном цикле и Сатана благословит твою дальнейшую еблю в поиске этой ошибки.
Мне кажется это прямо отдельный вид программирования. В котором сочетается полет инженерной мысли и знания синтаксиса языка)
мы тут вообще придерживаемся религии бога нашего Рефакторинга и пророка его Мартина фаулера
я и.о. ведущего инженер-программиста в бюджетной организации, если код подопечных работает без ошибок, то и бог с тем как он написан, с нашей зарплатой и это хорошо.
не факт, что нас к тому времени не сократят, да и если нечего будет чинить - тогда точно сократят.
А вообще проекты не настолько сложные, скорее однообразные и унылые, поэтому с этим работать лень.
Да и говнокод если умеешь разбирать в нем правки внести не проблемно. Да потеряю не 15 минут, а пару часов работы, но так - рабочее время идет - зарплата капает.
пробовал, теперь коллеги в моем коде вообще ничего найти не могут и что-то подправить без меня, особенно если там фабрика и кучка всего через интерфейсы.
Мало уметь хорошо писать - надо еще и работать в коллективе, который хорошо пишет, либо хотя бы хочет хорошо писать
То, что бесконечным он будет только в одном случае - если опечатка прокралась в условие выхода внутреннего цикла
А помимо этого есть еще куча веселых штук, которые херят результат весьма непредсказуемым образом
Итый столбец
Житая строка
(мог перепутать)
Всегда в универе прикалывало, как препод, с таким непоколебимым лицом, серьёзно говорила
В Фортране наоборот было, хотя это не от языка зависит, а от общепринятого использования.
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору