раскрыть ветку (133)
раскрыть ветку (100)
раскрыть ветку (17)
На фотке индус, он не использует циклы
Он пишет
$sum=1+2+3+4+5+.......+99997+99998+99999;
echo $sum;
раскрыть ветку (16)
раскрыть ветку (14)
Это не важно. Важно что запись длинная и кринжовая. Индусы - это негры программисты, которые получают деньги за количество строк или количество символов в коде. И чтобы увеличить длину кода - делают такой хуевый код. Я как-то видел код, в котором число пи заново высчитывали в процессе инициализации через квадратуру круга.
Это как навык катания на чем-либо. Если один раз увидеть индусский код - всегда его отличишь среди другого кода.
раскрыть ветку (3)
Один "ваб сарвар" чего стоит. Думаю насчет кода так же кровь из глаз идёт при их виде
З.ы. к IT никакого отношения не имею, но примерно понимаю
З.ы. к IT никакого отношения не имею, но примерно понимаю
раскрыть ветку (6)
раскрыть ветку (2)
раскрыть ветку (1)
Господи благослови редактирование комментариев.
Когда жму кнопку "отправить", приходит идея как сказать лучше
foreach бесит немного когда пытаешься дебажить, или стэктрейс выдает первую строку, хотя упало где-то посередине.
раскрыть ветку (1)
раскрыть ветку (65)
ещё комментарии
Любой. В любом языке с foreach есть своя реализация стека и очереди. И если привести их к общему интерфейсу, то хрен ты угадаешь, в каком порядке тебе сейчас пойдут значения при обходе, в том же, в котором ты их туда клал или в противоположном.
раскрыть ветку (28)
Что значит "привести реализации стека и очереди к общему интерфейсу"? foreach в каждом языке где он имеется, уже, собственно, реализован, куда и к чему вы его будете приводить? Некоторые из реализаций гарантируют порядок обхода.
раскрыть ветку (10)
Это значит, дорогой мой профессионал, в случае шарпов, например, вот это: (IEnumerable)myStack и (IEnumerable)myQueue
раскрыть ветку (9)
Ну так а речь-то не об конкретном интерфейсе в конкретном языке, а о разнице в реализации в разных языках. Во-первых есть языки, где foreach не метода для интерфейса, а функция, тот же JS. Во-вторых в том же шарпе реализация IEnumerable для List'а гарантирует порядок. Сам интерфейс его чаще всего не гарантирует, это да.
раскрыть ветку (8)
не передергивайте, окей? в данной ветке кое-кто не понял что означает фраза "привести к общему интерфейсу". я пояснил. в случае шарпов, например, этот интерфейс реализуют все коллекции, если хотят быть перечисленными в foreah. и "привести" означает, что коллекции берутся как как объекты своих типов, а как объекты, реализующие IEnumerable, что, в свою очередь скрывает тип коллекции. в других языках есть полностью аналогичные механизмы, но я не статью на хабр пишу, чтобы их ту все перечислять. если знаете какой-то язык - понимаете о чем я.
раскрыть ветку (7)
Правильно не понял, потому что нельзя привести типы данных из разных языков к одному интерфейсу, это бред. Тем более что вы это сформулировали, ещё раз, "привести реализации стека и очереди". Реализации вообще ни к чему никуда не приводятся, ни в одном языке, приводятся типы, а точнее даже экземпляры типов, объекты. И статья на Хабре тут ни при чём - вы просто напутали с терминологией, да ещё и а контексте разных языков.
К чему вы мне начали объяснять работу перечисляемых типов в шарпе - я не понял. В разных языках это работает по разному, и не везде есть схожий механизм.
раскрыть ветку (6)
да это вы тут смешали все в одну кучу. в каждом языке есть реализация стека и очереди. если взять в каком-то языке местные реализации стека и очереди, это будут типы, ясен красен. реализация, если что, это как раз какой-то тип, реализующий некую логику. логика очереди и стека не зависит от языка, да? но каждый язык имеет собственную реализацию этих абстракций, иногда даже не по одной.
любой язык (окей, мой косяк, я всю дорогу имел в виду ооп языки) имеет механизмы абстрагирования. и я вел речь именно о том, чтобы абстрагировать два типа, реализующих логику очереди и стека, до абстракции уровня "это можно перечислить". в таком случае невозможно понять, в каком порядке будет перечисление, так как истинный тип скрыт за абстракцией.
раскрыть ветку (5)
любой язык (окей, мой косяк, я всю дорогу имел в виду ооп языки) имеет механизмы абстрагирования. и я вел речь именно о том, чтобы абстрагировать два типа, реализующих логику очереди и стека, до абстракции уровня "это можно перечислить". в таком случае невозможно понять, в каком порядке будет перечисление, так как истинный тип скрыт за абстракцией.
Ну я же с этим уже согласился. Только вот на практике, если ты знаешь какой именно тип ты итерируешь, то реализация интерфейса итератора может гарантировать порядок.
в каждом языке есть реализация стека и очереди. если взять в каком-то языке местные реализации стека и очереди, это будут типы, ясен красен.
Нет. Во-первых, только в ООП это будут типы, во-вторых, тип, реализация и реализация типа - три разные вещи. Реализацию никуда нельзя привести, я вам только что это написал. "Ясен красен реализация это тип" это чушь. Ясен красен транспортное средство это чертёж мотоцикла.
реализация, если что, это как раз какой-то тип, реализующий некую логику.
Реализовать можно по разному, в том числе и функциями, за исключением чистых ООП языков, которых по пальцам перечислить, Java да C#.
но каждый язык имеет собственную реализацию этих абстракций, иногда даже не по одной.
В том-то и дело.
раскрыть ветку (4)
ладно, я вижу, вы слова не очень понимаете, забьем. код посмотрите. https://pastebin.com/Y2fyeK6d
по коду не понятно, что итерируясь по интерфейсу нельзя угадать порадок?
раскрыть ветку (3)
итерируясь по интерфейсу нельзя угадать порадок
Я где-то сказал, что по интерфейсу можно угадать порядок?
Тем не менее, в обоих случаях в вашем коде порядок можно "угадать". Естественно не по интерфейсу, а по использованным для получения интерфейсов типам, а конкретно по строкам 10 и 11.
Если мы посмотрим на официальные примеры использования итератора, то мы можем видеть, что для Stack'а он LIFO, а для Queue - FIFO.
https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
Конкретно в случае Microsoft'а и C#па, порядок итерирования явно не документирован. Почему - хер его знает, потому что поменять его будет полнейшим безумием, и Microsoft явно предполагает, что порядок известен будет.
Если взять другой язык, например, Kotlin, то там есть отдельный интерфейс, гарантирующий порядок перечисления.
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti...
А ещё не забывайте, что вся эта дискуссия ведётся в контексте искусственного сужения круга языков до ООП, которые вы ввели, потому что иначе все ваши слова не несут никакого смысла.
раскрыть ветку (2)
але, форыч находится не на 10й и не на 11й строке, а на 35й. один и тот же метод, один и тот же форыч. два разных результата. именно потому что порядок определяет не форыч, а то, по чему он проходит. а это значит, что форыч не несет ответственности за порядок перечисления, а следовательно, не гарантирует его. логично?
Если мы посмотрим на официальные примеры использования итератора, то мы можем видеть, что для Stack'а он LIFO, а для Queue - FIFO.
я об этом и талдычу уже десятый коммент. порядок определяется не форычем, а коллекцией. и если в момент перечисления ты не знаешь, что за коллекция перед тобой - то ни в жизнь не угадаешь в каком порядке будут перечисляться значения.
отдельный интерфейс, гарантирующий порядок перечисления.
я тоже могу отдельный интерфейс написать, гарантирующий что угодно. проблема в том, что foreach - не интерфейс,
искусственного сужения круга языков до ООП
я уже извинился за то, что подразумевал ооп, но не сказал об этом с самого начала. если не хотите говорить об ооп - не отвечайте дальше. впрочем, ооп - это примерно 90% современного кода
раскрыть ветку (1)
я об этом и талдычу уже десятый коммент. порядок определяется не форычем, а коллекцией. и если в момент перечисления ты не знаешь, что за коллекция перед тобой - то ни в жизнь не угадаешь в каком порядке будут перечисляться значения.
А где я отрицал-то это, господи боже мой?
я тоже могу отдельный интерфейс написать, гарантирующий что угодно. проблема в том, что foreach - не интерфейс
А оператор работающий с интерфейсом. В случае котлина есть forEach, работающий над интерфейсом гарантирующим порядок перечисление. Это значит, что даже в ООП есть foreach, гарантирующий порядок. Всё, все ваши изначальные утверждения уже не правда, а разговор - бессмысленен.
Я не отрицал ни единого предложения из вашего последнего комента, о чём вы спорите - я решительно не понимаю.
Так сказал, будто в случае с for порядок гарантируется.
Итерирование - это не про порядок, а про обход. Какой будет порядок - зависит от много чего.
Ну и да, во многих языках есть структуры, которые foreach обходит по порядку. Тем не менее нельзя считать, что ты получишь тот порядок, который был, когда ты туда складывал, ибо мутабельность и многопоточность.
раскрыть ветку (1)
ибо мутабельность и многопоточность
В этом случае обходить вообще будет некорректно.
Либо мутабельность, либо блокировки)
Что за херню вы несете?
Покажите пример когда вы положите в List (мы про же про Шарп?) 1,2,3,4,а потом через foreach вы выведите 4,3,2,1. И при этом обращение через индекс будет выводить правильную последовательность.
раскрыть ветку (5)
мы про же про Шарп?
Даже в Шарпе я могу запилить свою собственную реализацию IEnumerable с блекджеком и шлюхами и будет вам какой угодно порядок, хоть рандомный каждый раз.
раскрыть ветку (3)
раскрыть ветку (2)
От 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 и почему вдруг я не могу знать, итерирую я стек или очередь?
раскрыть ветку (7)
потому что для итерирования не нужно знать конкретный тип. а не зная конкретного типа невозможно угадать в каком порядке будет перечисление: https://pastebin.com/Y2fyeK6d
раскрыть ветку (6)
там выше речь шла про гарантированность порядка обхода, в твоём примере он гарантирован структурой, которую ты итерируешь, а то, что ты забыл, что итерируешь к делу не относится.
раскрыть ветку (5)
давай я тебе накидаю енумератор в три строки, который значения по рандому выдавать будет, если тебе так хочется?
что значит, забыл? в реальном коде ты частенько и не знаешь, что ты итерируешь. перечисляемое и ладно. там может быть вообще никакой коллекции нет, за этим интерфейсом.
раскрыть ветку (1)
я больше скажу. foreach не только порядок не гарантирует, он не гарантирует, что значения вернутся все, не гарантирует, что при повторном итерировании значения будут в том же порядке, или хотя бы те же, не гарантирует даже, что повторное итерирование в принципе возможно. он вообще ничего не гарантирует
раскрыть ветку (2)
раскрыть ветку (1)
про какой язык говорить
так и в каком языке форыч гарантирует порядок? именно сам по себе оператор foreach?
и какую структуру итерировать
так в том и смысл, что порядок определяет не оператор, а структура. foreach - не структура
ещё комментарии
С какой стати? Единственное неудобство forEach - не видно индекс. А вообще сейчас почему-то все вместо for-ов по map-ам угорают и прочей функциональщине.
раскрыть ветку (9)
Может быть, map-reduce хорошо параллелятся, поэтому в современности на них налегают?
Ну и читается `let squares = numbers.map(x => x*x)` куда лучше чем что-то типа `for (int i = 0; i < numbers.length; i++) squares.push(numbers[i]*numbers[i])`
раскрыть ветку (1)
Приведи пример, когда тебе так уж нужен индекс обрабатываемого значения в коллекции, если у тебя и так есть само значение
раскрыть ветку (2)
Например, импорт юзеров из файла (с логинами и хэшами паролей). Если что-то пошло не так, кидаем экспепшн, но указывать sensitive data нехорошо, логично указать номер строки где произошла ошибка (и тут нам нужен индекс).
раскрыть ветку (10)
Безусловно. И в большинстве случаев таки по порядку обходит. Но не гарантирует.
Это как сортировка набора данных: хочешь гарантированно - пиши order by
Это как сортировка набора данных: хочешь гарантированно - пиши order by
раскрыть ветку (9)
Гарантии определяются типом коллекции, которую мы собираемся обходить. Если порядок элементов задается натуральным образом, то обходить мы их будем по порядку.
Сюда можно подтянуть нюансы с параллельной обработкой коллекций, но это уже другая история.
раскрыть ветку (6)
раскрыть ветку (5)
раскрыть ветку (3)
ну, вот в крестах, например, оно компиляется в итератор и если мы итерируем вектор, например, то там вполне гарантированн порядок элементов
раскрыть ветку (2)
раскрыть ветку (9)
В разных языках по разному. К тому же сильно зависит от реализации того объекта, по которому идёт итерация.
раскрыть ветку (8)
Вот не надо этого "в разных языках" и "сильно зависит от реализации". Не "сильно зависит", а "полностью определяется". В результате порядок обхода в "for-each" гарантируется быть таким, как его реализовал создатель контейнера. Согласитесь, есть большая разница с "не гарантируется".
for-each со слегка разным синтаксисом есть в C++, Java, Python, C# - везде это обход коллекции по порядку, определённому коллекцией. В каких это "разных языках" по-другому? Вася Пупкин - экспериментатор написал язык Mother Fucker, где по-другому, и с тех пор в разных языках по-разному?
for-each со слегка разным синтаксисом есть в C++, Java, Python, C# - везде это обход коллекции по порядку, определённому коллекцией. В каких это "разных языках" по-другому? Вася Пупкин - экспериментатор написал язык Mother Fucker, где по-другому, и с тех пор в разных языках по-разному?
раскрыть ветку (7)
В результате порядок обхода в "for-each" гарантируется быть таким, как его реализовал создатель контейнера. Согласитесь, есть большая разница с "не гарантируется".
Ну так это оно и есть, что порядок обхода коллекции может быть непредсказуем. Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции. А вот в каком порядке оно их выдаст - зависит от того, что там разработчик намудрил.
раскрыть ветку (5)
Эта ветка началась с вашего
foreach не гарантирует порядок обхода.
Это по-прежнему не так. for-each, как конструкция языка, гарантирует порядок обхода в соответствии с порядком, определённым коллекцией.
Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции
Неверно. Ни намёка на такую гарантию нет. Что, элемент "17" не может быть возвращён два раза при проходе по вектору?
порядок обхода коллекции может быть непредсказуем
Да, некоторые коллекции определены так, что порядок их обхода не определён. Но "порядок может быть непредсказуем для определённых коллекций" никак не транслируется в "foreach не гарантирует порядок обхода".
"Коллекция" вообще дугая сущность, нежели конструкция "for-each". Из неопределённости порядка для некоторых видов первой никак не следует неопределённость работы второй.
А вот в каком порядке оно их выдаст - зависит от того, что там разработчик намудрил.
Вам по не понятной причине кажется, что существование неупорядоченных коллекций настолько важно и всеобъемлюще, что оно должно обобщаться до "у коллекций нет гарантий упорядоченности". У большинства видов коллекций такая гарантия есть. Ну да, есть одна, у которой нет. Опять же, это не касается for-each.
раскрыть ветку (1)
Неверно. Ни намёка на такую гарантию нет. Что, элемент "17" не может быть возвращён два раза при проходе по вектору?
Я, наверное, чего-то не знаю?
Единственная гарантия - не выдаст один и тот же элемент 2 раза при неизменной коллекции.
Нет такой гарантии. Ибо кольцевые буферы.
В C#, например, решарпер будет ворнинг об этом кидать при попытке итерации даже через простой IEnumerable.
раскрыть ветку (2)
Нет такой гарантии. Ибо кольцевые буферы.
Хм... Действительно. Ну вот в голову бы не пришло такое через foreach делать. К вопросу о.
раскрыть ветку (1)
Вам - не придет. А какой-нибудь коллега может заюзать высокоуровневый интерфейс (где в глубине подкапотного вы полагались на существование такой гарантии) и передав имплементацию кольцевого буфера потенциально получит бесконечный цикл (=
ещё комментарии
j - это всё... Написал по ошибке вместо j i во вложенном цикле и Сатана благословит твою дальнейшую еблю в поиске этой ошибки.
раскрыть ветку (12)
раскрыть ветку (8)
раскрыть ветку (7)
Мне кажется это прямо отдельный вид программирования. В котором сочетается полет инженерной мысли и знания синтаксиса языка)
раскрыть ветку (6)
На самом деле нет, моя должностная обязанность в том числе содержить пункты о поддержании чистоты кода и разработке чистой архитектуры.
мы тут вообще придерживаемся религии бога нашего Рефакторинга и пророка его Мартина фаулера
мы тут вообще придерживаемся религии бога нашего Рефакторинга и пророка его Мартина фаулера
раскрыть ветку (5)
я и.о. ведущего инженер-программиста в бюджетной организации, если код подопечных работает без ошибок, то и бог с тем как он написан, с нашей зарплатой и это хорошо.
раскрыть ветку (4)
раскрыть ветку (3)
не факт, что нас к тому времени не сократят, да и если нечего будет чинить - тогда точно сократят.
А вообще проекты не настолько сложные, скорее однообразные и унылые, поэтому с этим работать лень.
Да и говнокод если умеешь разбирать в нем правки внести не проблемно. Да потеряю не 15 минут, а пару часов работы, но так - рабочее время идет - зарплата капает.
раскрыть ветку (2)
А вы не пробавали сразу хорошо писать? Почитайте умные книжки про ООП, архитектуру, рефакторинг и паттерны
раскрыть ветку (1)
пробовал, теперь коллеги в моем коде вообще ничего найти не могут и что-то подправить без меня, особенно если там фабрика и кучка всего через интерфейсы.
Мало уметь хорошо писать - надо еще и работать в коллективе, который хорошо пишет, либо хотя бы хочет хорошо писать
раскрыть ветку (1)
То, что бесконечным он будет только в одном случае - если опечатка прокралась в условие выхода внутреннего цикла
А помимо этого есть еще куча веселых штук, которые херят результат весьма непредсказуемым образом
Итый столбец
Житая строка
(мог перепутать)
Всегда в универе прикалывало, как препод, с таким непоколебимым лицом, серьёзно говорила
раскрыть ветку (7)
Обычно наоборот, "итая" строка. Так называемый row major порядок, строки переключаются во внешнем цикле, по i, а столбцы - во внутреннем, по j.
В Фортране наоборот было, хотя это не от языка зависит, а от общепринятого использования.
В Фортране наоборот было, хотя это не от языка зависит, а от общепринятого использования.
раскрыть ветку (3)
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору