- 1
std::ranges::for_each(tasks, [](auto x) {x();});
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
std::ranges::for_each(tasks, [](auto x) {x();});
а ещё теперь не нужно писать std::begin(), std::end().
c++ будущего.
bormand 10.05.2021 10:07 # +1
Soul_re@ver 10.05.2021 10:17 # +4
bootcamp_dropout 10.05.2021 10:53 # +4
Foreach = декларативность, функциональность, молодость, стиль
booratihno 10.05.2021 10:56 # +2
А форыч это, всё таки, Черч
3_dar 10.05.2021 12:52 # 0
booratihno 10.05.2021 14:41 # 0
3_dar 10.05.2021 12:51 # +1
PolinaAksenova 10.05.2021 14:44 # +2
booratihno 10.05.2021 14:48 # +1
но ленивости (генеаторов) всё равно не будет из коробки, угу
PolinaAksenova 10.05.2021 14:56 # +2
booratihno 10.05.2021 16:17 # +1
можно как-бы сделать (псевдокод)
будет как питон с его map и прочим itertools
но в питоне есть генераторы, а тут нету, и если питухов 100000 то багор
PolinaAksenova 10.05.2021 16:28 # 0
> take_first(10, sort(&sorter, petuhi.begin(), petuhi.end()))
Только тут же возникает проблема: что возвращает sort() и что принимает take_first()? В итераторном коде сигнятура take_first() выглядела бы примерня как "(void) take_first(size_t count, It begin, It end, OutIt outBegin)", и в неё sort() някак ня впихнуть.
А вот благодаря миксиняшкам такие проблемы решаются тривиальня.
booratihno 10.05.2021 16:41 # 0
но это всё не лениво, а значит весьма сомнительно
PolinaAksenova 10.05.2021 16:47 # 0
Так вот имення чтобы ня принимать коллекцию и делались итераторы. Чтобы ты мог, няпример, легко и просто отсортировать половину коллекции: "std::sort(collection.begin() + collection.size() / 2, collection.end())".
А ещё так нячинают возникать проблемы: а что, если я хочу получить из sort() ня vector, а, няпример, list? А что делать с кастомными аллокаторами? А что, если я хочу в take_first засунуть map, а получить vector? И так далее.
Вот чтобы таких проблем ня было — и придумали итераторы. Ты сам создаёшь контейнеры, которые тебе нужны, а функции оперируют только няд итераторами. Но, как показала практика, это была далеко ня самая лучшая идея.
booratihno 10.05.2021 17:04 # 0
имхо, итератор это хорошо, просто небыло красивых средств для ленивости, и потому половина функционала была недоступна..
а вот твой пример с /2 отлично работал же, да и независящие от контейнера алгоритмы -- тоже
PolinaAksenova 10.05.2021 17:16 # 0
2. Отсутствие чейнинга. Тут всё и так понятно: вместо няшного sort().filter().map().reduce() приходится писать гигантские вербозные портянки.
3. Няобходимость в std::(back_|front_)?inserter для вставки результата в изнячальня пустой/маленький контейнер.
4. Общая высокая вербозность, особення в базовых (в том числе и самых распространённых) случаях. Вместо collection.sort() / sort(collection) — sort(collection.begin(), collection.end()).
bormand 10.05.2021 17:17 # +2
Особенно сраная пара remove/erase, про которую так любят спрашивать на собеседованиях.
PolinaAksenova 10.05.2021 17:18 # +1
booratihno 10.05.2021 17:24 # 0
один питух двигает говно, а второй чистит вилкой освободивщееся место если я верно помню
Soul_re@ver 10.05.2021 17:27 # +2
К — Консистентность.
booratihno 10.05.2021 17:28 # 0
да, это отсос. В руби я могу сделать цепочку от 0 до бесконечности, и выбрать из нее по условию первые N элементов, а тут фиг
>Отсутствие чейнинга.
угу( ну вот это как раз как в питоне тоже, и это плохо. А вот в руби... ну ты понял)
> std::(back_|front_)?inserter
А иначе как контейнер расширится?
Итератор в векторе или массиве же это просто указатель на элемент ЗА хвостом, верно?
Как же можно сделать так, чтобы при писании туда вектор бы расширялся?
>Общая высокая вербозность
Угу(( но без итераторов было бы еще вербознее
bormand 10.05.2021 17:30 # 0
Ну вот поэтому range -- это более красивая концепция чем итератор.
booratihno 10.05.2021 17:32 # 0
но и итератор на момент с03 тже было круто имхо
PolinaAksenova 10.05.2021 17:34 # 0
А в ranges вообще ничего ня надо расширять. После серии преобразований ты получаешь ленивый генератор, который вообще някуда записывать ня надо: ты можешь итерироваться сразу по няму.
Но даже если вдруг понядобилось материализовать — ты просто пишешь условный ... | ranges::to<std::vector> и получаешь всё в лучшем виде.
bormand 10.05.2021 17:25 # +3
Да это миф, на самом деле. Я вот сходу даже не назову алгоритм, который ну совсем прям на любом контейнере работает.
Везде или какие-то подвохи с вычислительной сложностью std::find(map.begin(), map.end(), x) vs map.find(x) или какой-то постпроцессинг в духе v.erase(std::remove(v.begin(), v.end(), x), v.end()) нужен.
Soul_re@ver 10.05.2021 17:28 # +2
Ну, они обычно РАБОТАЮТ. Стоит ли так работать, или нет — это другой вопрос.
booratihno 10.05.2021 17:31 # 0
просто итераторов бывает много разных: кто-то поддерживает арифметику, кто-то поддерживает запись, итд
bormand 10.05.2021 17:40 # +1
* На всех кастомных контейнерах, которые косплеят соответствующий стандартный.
А поскольку в стандартной либе все контейнеры разные, каких-то общих алгоритмов у них очень мало получается. По сути каждый алгоритм под что-то конкретное нужен. И во многих местах вместо них надо брать кастомную версию из самого класса и т.п. Консистентность на высоте.
Короче не особо взлетела эта идея, имхо.
booratihno 10.05.2021 17:44 # 0
Это был бы булщит уровня "локальный вызов заменим удаленным вызовом по HTTP, а алгоритм останется тем же" (над этим еще Фаулер ржал в 2003-м), но какие-то алгоритмы всё таки можно переиспользовать
bormand 10.05.2021 17:47 # 0
А какие? Ну вот банальный find. Он работает, по сути, только на листе и не отсортированном векторе. Для мапы/хешмапы надо брать их реализацию, которая за логарифм ищет. А для отсортированного вектора есть binary_search, который на отсортированном листе бесполезен.
Так и живём.
booratihno 10.05.2021 17:51 # 0
Я пишу алгоритм, который итерируется по нему и выводит значение если оно полдходит по условию. Что не так?
Про find: с этим даже джависты отсосали: там вроде поиск в массиве работает только если он сортирован, именно ради бинари сёч
но если мне похуй на перфоманс, я могу написать поиск за O(N) и он будет работать на чем угодно, не?
PolinaAksenova 10.05.2021 17:54 # −1
Но тогда теряется смысл в специализированных контейнерах. С тем же успехом можня хранить всё в std::vector.
booratihno 10.05.2021 17:56 # 0
А вдруг я ищу что-то в алгоритме раз в 10 лет, а всталяю в середину каждые 1ms, и тогда мне важно взять именно list?
bormand 10.05.2021 17:55 # +1
Ну ок, transform/copy действительно для всех контейнеров работают (на входе). Целых джва алгоритма уже нашли!
Soul_re@ver 10.05.2021 17:58 # +1
форич/_н
count/count_if
mismatch
adjacent_find
search/_n
Все что требует не лучше ForwardIterator
bormand 10.05.2021 18:00 # 0
search (не путать с find!) на мапе или хешмапе очень полезен, конечно... Хотя иногда что-то и найдёт, наверное.
Soul_re@ver 10.05.2021 18:09 # 0
PolinaAksenova 10.05.2021 18:05 # +2
(╥﹏╥)
Soul_re@ver 10.05.2021 18:18 # +2
(╥﹏╥)
Действительно плохой алгоритм.
PolinaAksenova 10.05.2021 18:45 # +1
Это просто ещё один пример потёкшей абстракции.
booratihno 10.05.2021 17:58 # 0
Спрятать алгоритмы в сами контейнеры, потому что независящий от контейнера алгоритм часто просто не написать?
А мне вот нравится, что у вектора и умассива общие алгоритмы, а в джаве -- нет..
CHayT 10.05.2021 18:01 # 0
j123123 12.05.2021 10:28 # 0
А вот взять например метод sort, который есть у std::list и у std::forward_list. А у вектора никакого метода sort нет, используйте std::sort.
Зачем? Зачем? std::sort требует random access iterator и поэтому для std::list и std::forward_list нельзя std::sort, а для std::vector можно? А почему тогда не сделать так, чтоб и у std::vector был метод sort, ну, типа для единообразия?
j123123 12.05.2021 10:51 # 0
j123123 12.05.2021 11:01 # 0
> Учителям такой категории вообще, судя по всему, всё до лампочки: в C++ используется библиотека STL, а значит, надо рассказать ученикам STL; разумеется, дальше vector'а и list'а обучение никогда не заходит (при этом эти два контейнера, пожалуй, самые бесполезные из всего STL), но самое интересное, что ученики, разумеется, так и не понимают, о чём идёт речь. В самом деле, как можно объяснить разницу между vector и list человеку, который никогда в жизни не видел ни динамических массивов, ни списков и вообще не понимает, что такое указатель? Для такого ученика list отличается от vector тем, что в нём нет удобной операции индексирования (почему её там нет? ну, нам что-то объясняли, но я ничего не понял), так что вообще-то всегда надо использовать vector, ведь он гораздо удобнее. Что? Добавление в начало и в середину? Так оно и для вектора есть, какие проблемы. Ну да, нам говорили, что это «неэффективно», но ведь работает же! Переучить такого ученика практически нереально: попытки заставить его создать односвязный список вручную обречены на провал, ведь есть же list, а тут столько ненужного геморроя! Собственно говоря, всё: если нашему обучаемому дали в руки STL раньше, чем он освоил динамические структуры данных, то знать он их уже не будет никогда; путь в серьёзное программирование ему, таким образом, закрыт.
PolinaAksenova 12.05.2021 11:23 # 0
Имення поэтому учить программированию нядо с C.
guest6 12.05.2021 11:33 # 0
PolinaAksenova 12.05.2021 11:41 # +1
^_^
guest6 12.05.2021 11:42 # 0
KoWe4Ka_l7porpaMMep 12.05.2021 11:36 # 0
guest6 12.05.2021 11:41 # 0
KoWe4Ka_l7porpaMMep 12.05.2021 11:41 # 0
guest6 12.05.2021 11:43 # 0
KoWe4Ka_l7porpaMMep 12.05.2021 11:45 # 0
booratihno 12.05.2021 15:18 # +1
хуже только сразу учить их на каком-нить питоне или JS.
В случае крестов они хотябы будут знать, что бывают массивы, а бываюи сваязанные списки
В случае питона они не будут знать ничево, и не отличать объект от указателя
bormand 12.05.2021 15:21 # +1
Именно поэтому я за "РНР".
MAKAKA 12.05.2021 16:33 # +3
Только выкинуть, и нового родить
digitalEugene 16.05.2021 16:04 # +1
bormand 10.05.2021 17:49 # +1
booratihno 10.05.2021 17:53 # 0
CHayT 10.05.2021 17:57 # +1
j123123 10.05.2021 18:58 # 0
Контейнеры-хуёйнеры какие-то блядь. Как всё сложно. Предлагаю кложуру и хэшмап
https://youtu.be/b-Eq4YV4uwc?t=1607
https://youtu.be/b-Eq4YV4uwc?t=1724
PolinaAksenova 10.05.2021 19:06 # −1
j123123 10.05.2021 19:10 # 0
PolinaAksenova 10.05.2021 19:11 # −1
j123123 10.05.2021 19:12 # 0
PolinaAksenova 10.05.2021 19:15 # −1
https://www.youtube.com/watch?v=ouUloBNBhOA
> И std::kokoнтейнеров из крестоговна тоже нет.
Тебе ня придётся учить стандартную библиотеку, если каждый раз ты пишешь стандартную библиотеку сам╰(▔∀▔)╯!
j123123 10.05.2021 19:18 # 0
Стандартная библиотека крестоговна мне там банально не подходит т.к. там требуется какой-то хип, а у меня в контроллерах может не быть никакого хипа (если всё решаемо статической памятью), а еще там какие-то исключения RTTI и прочая такая питушня, которая мне в контроллерах няхуй не нужна. Да и в целом можно поднасобрать каких-то реализаций различной питушни на сишечке с гитхаба, и ее использовать вместо крестовой говностдлибы.
PolinaAksenova 10.05.2021 19:20 # 0
Зачем?
> исключения RTTI
-fno-exceptions -fno-rtti
> Да и в целом можно поднасобрать каких-то реализаций различной питушни на сишечке с гитхаба, и ее использовать вместо крестовой говностдлибы.
И собрать свою говнолибу.
j123123 10.05.2021 19:26 # 0
> Зачем?
Память выделять там, например для какой-нибудь там std::list питушни. Без хипа я могу например так сделать: https://govnokod.ru/23275
bormand 10.05.2021 19:29 # 0
Ну в бусте вроде были такие контейнеры... И интрузив списки, которые сишники любят делать руками тоже были.
А стд, конечно, очень сильно завязано на хип и исключения. 90% стандартной либы можно тупо выбросить под фристендингом.
PolinaAksenova 10.05.2021 19:32 # 0
Ну а вообще в том посте roman-kashitsyn всё правильня расписал.
bormand 10.05.2021 19:33 # 0
А как репортить ошибку, когда в нём место закончилось? Рушить абстракцию и приделывать аллокатору какое-нибудь has_enough_space()?
PolinaAksenova 10.05.2021 19:34 # 0
bormand 10.05.2021 19:35 # +1
Ну заебись для эмбеддеда... На какую-нибудь опциональную хуйню для UI памяти не хватило, весь чип ушёл в ребут.
j123123 10.05.2021 19:38 # 0
Настоящие цари заранее должны знать, что им там всего хватит под все возможные сценарии. Если вдруг памяти не хватает, это баг, и надо менять структуру или допаивать ОЗУ или менять контроллер
PolinaAksenova 10.05.2021 19:39 # −1
> Железка может уметь много чего делать, и ей может быть не нужно делать это одновременно (и памяти на одновременное делание всего у нее тоже нет). Поэтому железка может выделять память под някню№1, сделать някню№1, освободить память, выделить память под някню№2, сделать някню№2, освободить память. И эти хуйни№x может быть много, некоторые не сильно жрущие оперативку хуйни могут вполне работать одновременно, и они могут быть заранее неизвестны т.е. загружаться с внешнего флеш-накопителя или по блютузу какому-то скачиваться и устанавливаться, если это какая-то IoT-няшнота. Так что для каких-то задач это вполне себе пригождается.
https://govnokod.ru/27391#comment625630
j123123 10.05.2021 19:33 # 0
А аллокатор может возвращать uint8_t ? Ну типа это память не вообще, а память, выделенная в контексте некоторой арены, где мы адресуемся не по байтикам, а по блокам в 16 байтиков, и этот возвращаемый uint8_t это смещение относительно какого-то там указателя в этой арене, который надо еще на 16 умножить и прибавить к этому базовому адресу чтоб получить реальный адрес
PolinaAksenova 10.05.2021 19:37 # 0
bormand 10.05.2021 19:39 # 0
Не, он хочет что-то в духе кастомного std::vector::pointer. Чтобы там не настоящий поинтер был, а какой-то компактный тип, который можно через какую-то арифметику превратить в настоящий.
З.Ы. Ну кстати можно, походу. Этот тип из аллокатора берётся как раз. Если он будет вести себя как поинтер, то вектор схавает.
PolinaAksenova 10.05.2021 19:41 # −1
j123123 10.05.2021 19:40 # 0
А если не уменьшается, и если я не хочу хранить полный указатель под каждую хрень? Есть один настоящий указатель, и куча смещений от него, и эти смещения влезают uint8_t без проблем.
bormand 10.05.2021 19:42 # 0
Ну там в трейтах аллокатора можно указать свой тип для pointer. Может и прокатит что-то кастомное, если прикрутить звезду и скобочки.
Просто uint8_t нельзя, конечно. Но структурка или енум с uint8_t могут прокатить.
j123123 10.05.2021 19:44 # 0
Трейты-хуёйты, может и прокатит, а может не прокатит... Ясно всё.
Сколько надо будет с этим примерно ебаться, и много ли я от этого выиграю на своих задачах?
bormand 10.05.2021 19:46 # 0
Х.з., я тут только пессимистичный прогноз могу дать. Наебавшись с тем же boost intrusive списком, я тупо выбросила его няхуй и написала свой за 5 минут.
PolinaAksenova 10.05.2021 19:46 # −1
Кстати, std::list хранит ня указатели, а Allocator::pointer, так что можня попробовать упороться с таким аллокатором. Но лучше, конечно, использовать нярмальные intrusive list.
bormand 10.05.2021 19:47 # 0
Списку, который на основе этого аллокатора работает, нужны указатели. Ну и тратить на них по 4 байта не хотелось бы, если список маленький.
> нярмальные intrusive list
Их, кстати, довольно сложно юзать в режиме "несколько списков через одни и те же объекты"... При том, что внутри там ерунда по переключению линков, которая пишется буквально за 5 минут (и в ней даже условий нет, так что юнит-тест элементарен). Ну в данной конкретной задаче может быть и прокатят.
MAKAKA 10.05.2021 22:14 # 0
bormand 10.05.2021 22:47 # 0
Да, ссылки ты размещаешь в объекте сам и поясняешь либе как ими пользоваться.
MAKAKA 10.05.2021 22:54 # 0
Так-то ты мог свой итератор со своим ++ написать и в 03 еще
bormand 10.05.2021 23:01 # 0
Скорее оставляешь управление памятью за собой, как в сишке. А "контейнер" даёт тебе attach/detatch вместо insert/remove.
В теории могло бы быть полезно, когда тебе надо 2-3 списка построить через одни и те же ноды. Но на практике мне не удалось запинать эти злоебучие трейты, пришлось решать эту задачу руками.
MAKAKA 10.05.2021 23:02 # 0
Делаешь один связанный список, и по нему строишь два других списска: один напрямую, другой через один, например?
bormand 10.05.2021 23:03 # 0
Это всё решается и на обычных контейнерах, конечно. Но по памяти/пирфомансу будет совсем не айс.
MAKAKA 10.05.2021 23:12 # 0
Тем, что придется обёртку делать на каждый такой указатель?
bormand 10.05.2021 23:16 # 0
Ну получается слишком много мелкой хуйни и аллокаций для неё. Если у тебя какие-нибудь треды тыщи раз в секунду просыпаются и засыпают, как-то стрёмно аллокатор дрочить каждый раз. Особенно если в этих местах аллокатор вообще трогать нельзя.
А с интрузивом оно интегрировано в основную структуру. Ну как сишник бы сделал.
MAKAKA 10.05.2021 23:18 # 0
bormand 10.05.2021 23:19 # 0
А в самих "контейнерах", по сути, только башка этих списков/деревьев.
MAKAKA 10.05.2021 23:22 # 0
bormand 10.05.2021 23:46 # 0
guest6 10.05.2021 23:55 # 0
CHayT 10.05.2021 23:55 # 0
Спасибо, ты прям вернул говнокод 2010-го.
PolinaAksenova 11.05.2021 00:03 # 0
В крестах, кстати, есть std::make_shared(). По Стандарту std::make_shared() обязана делать только одну аллокацию, сшивая управляющий блок с данными. Так что shared_ptr, сделанный через make_shared(), и shared_ptr, сделанный через конструктор — две очень большие разницы.
guest6 11.05.2021 00:09 # 0
PolinaAksenova 11.05.2021 00:13 # 0
MAKAKA 11.05.2021 00:22 # 0
блядь, какой С++ сложный
шарик помрет, потому что померло всё выражение, а Bar никто не делитнул, вот он и остался, верно?
шарик тут суть вообще временный обхект же
PolinaAksenova 11.05.2021 00:34 # 0
Во всяком случае, так было раньше, а теперь уже всё отличня.
> Начиная с c++17 утечка памяти в том хитром редком примере, ради которого в STL был добавлен std::make_shared, уже невозможна.
Soul_re@ver 11.05.2021 00:12 # +2
Проблема в том что этот ресурс — по сути дела struct { char[8294400] }.
PolinaAksenova 11.05.2021 00:14 # 0
> make_shared
Какой эпичный выстрел в ногу!
guest6 10.05.2021 22:31 # 0
а потом дальние и ближние указатели
j123123 10.05.2021 19:27 # 0
Которая не будет всякую ненужную питушню треботвать, и будет эффективна по потреблению памяти.
MAKAKA 10.05.2021 22:03 # +2
> раз ты пишешь стандартную библиотеку сам
"В Go распространен подход к выполнению большенства рутинных задач явно, уменьшая сложность понимания кода"
буду теперь форсить эту фразу везде
ASD_77 11.05.2021 11:25 # 0
bormand 11.05.2021 11:47 # +2
Что понимается под "нормальным"? Убожество как в джаве, дотнете или скриптушне, которое только для последовательного обхода пригодно?
Всё-таки крестовые итераторы пытались решить большую задачу, чем просто обход контейнера по порядку.
Soul_re@ver 11.05.2021 11:50 # +2
JloJle4Ka 11.05.2021 12:16 # 0
Пытались )))
А какой должен быть нормальный итератор? Какую глобальную проблему решили итераторы в крестах, которую в скриптушне решить не смогли? Допустим, в питоне.
bormand 11.05.2021 12:20 # +1
Указать на слайс контейнера чтобы удалить его или заменить на что-то другое, к примеру. Или (осторожно) удалять элементы из контейнера прям во время его обхода. Или найти элемент в мапе и записать в него новое значение не делая повторный поиск. Или даже проделать над ними какую-то арифметику(!), если random access.
В питоне, емнип, имея итератор ты вообще ничего не можешь сделать. Ну кроме как достать из него следующее значение.
Soul_re@ver 11.05.2021 12:26 # +2
Итераторы в крестах предназначались, как точка кастомизации. Захотел сделать итератор, который проходит по вектору строк и выдаёт только слова, имеющиеся в словаре, приведённые к нижнему регистру. Или проходит сначала по нечётным, а потом по чётным индексам — сделал, передал в имеющуюся функцию и всё работает.
bormand 11.05.2021 12:29 # +1
Ну просто для обхода хватило бы и убогого forward iterator'а, которым хвалятся джавы да питоны.
Хотя... их итератор даже на forward не тянет т.к. его нельзя передать в какой-нибудь erase() или заюзать как границу для последующего поиска.
Soul_re@ver 11.05.2021 12:34 # +1
bormand 11.05.2021 12:35 # +1
MAKAKA 11.05.2021 19:53 # +1
Но это не важно.
Важно, что они итераторы своего конца никогда не знают, и потому всякие крутые штуки как в крестах с ними не сделать
ASD_77 11.05.2021 17:42 # 0
JloJle4Ka 11.05.2021 12:41 # 0
Такое есть в скрипушне, а ещё в «Nim», кажется.
> Или (осторожно) удалять элементы из контейнера прям во время его обхода.
Такого, кажется, в скриптушне действительно нет. Раньше же итератор протухал как только его коллекцию как-либо меняли? Тогда крутая фича.
Хотя нет, в питоне можно вот так:
Это ведь итератор работает!
> В питоне, емнип, имея итератор ты вообще ничего не можешь
Это правда лишь отчасти. В питоне есть слайсы, генераторы и итераторы, которые делают всякие приколы. Я правильно понял, что «Ranges» просто совместил в себе все эти финтифлюшки? Справедливо ли утверждение, что крестобляди соснули, т.к. им пришлось комюпировать функционал из скриптушни? Или это скриптобляди поспешили и людей насмешили, а крестобояре обстоятельно подумали и сделали как надо?
Soul_re@ver 11.05.2021 13:12 # +1
JloJle4Ka 11.05.2021 13:13 # 0
PolinaAksenova 11.05.2021 14:21 # 0
Это удаление элемента по знячению. Об эффективнясти такого можня догадаться.
MAKAKA 11.05.2021 14:23 # 0
По идее нужно найти элемент за O(N) (если нет требования сортированности массива) и, удалив элемент, двигануть пол массива. Какой окшмар
PolinaAksenova 11.05.2021 14:24 # 0
MAKAKA 11.05.2021 14:28 # 0
если все, то логично сначала все найти, потом подвигать.
А нельзя явно заказать линкдлист вместо массива, если уж мы такие удалятели знатные?
PolinaAksenova 11.05.2021 14:47 # 0
> А нельзя явно заказать линкдлист вместо массива, если уж мы такие удалятели знатные?
Нят. Это слишком сложня для скриптов.
MAKAKA 11.05.2021 15:05 # +1
Именно потому я за перл: массив, хеш, да скляр. Всё
Soul_re@ver 11.05.2021 15:13 # +1
MAKAKA 11.05.2021 15:23 # 0
Берешь, и делаешь нужную структуру под конкретную задачу
Потому мне всегда смешно от сёмных нахрюков про "в си даже мапы нету"
вон сколько сложностей возникло в крестах из за STL контейнеров
bormand 11.05.2021 15:32 # +3
А в позиксе есть! Правда она одна на весь процесс и удалять из неё нельзя. Но это мелочи.
MAKAKA 11.05.2021 18:05 # 0
там вроде и массив есть с байнари сёрчем... такие костыли, конечно
Soul_re@ver 11.05.2021 18:20 # +1
MAKAKA 11.05.2021 18:30 # +1
bormand 11.05.2021 19:21 # 0
MAKAKA 11.05.2021 19:42 # 0
bsearch сишка
tsearch юникс
qsort сишка
ужасный раздрай) Правда, по заголовочному фалйу понятно
А в Win32 есть какинито алгоритмы интересные?
Или у MS позиция "юзайте STL, пишите на крестах"?
ASD_77 11.05.2021 17:40 # 0
bormand 11.05.2021 17:42 # 0
PolinaAksenova 11.05.2021 17:43 # +2
MAKAKA 11.05.2021 17:58 # 0
Soul_re@ver 11.05.2021 18:19 # +2
MAKAKA 11.05.2021 17:48 # 0
В С++ есть несколько категорий итераторов:
https://www.geeksforgeeks.org/introduction-iterators-c/
Самые тупые их них могут только выдавать значение (разыменовываться) или только двигаться вперед (++)
Самые продвинутые умеют даже random access.
Некоторые умеют писать или удалять данные
Все зависит от категории.
JloJle4Ka 11.05.2021 17:54 # 0
MAKAKA 11.05.2021 17:57 # +1
https://docs.microsoft.com/en-us/sql/relational-databases/cursors?view=sql-server-ver15
3ацени, кстати, сколько их типов разных
ASD_77 12.05.2021 18:24 # 0
Soul_re@ver 12.05.2021 19:46 # +1
* Доступа к возвращаемому значению генераторов посредством итераторов не сделать (ведь это, о боже, изменит значение генератора)
* Ленивых итераторов быть не может (ведь доступ к значению заставит это значение изменится, какой ужас)
* Абстрагировать поток как коллекцию значений с помощью итератора не получится (поток меняется от чересчур пристального взгляда на него, кошмар).
И нахуя нужны такие итераторы?
MAKAKA 12.05.2021 19:56 # 0
ASD_77 11.05.2021 17:41 # 0
CHayT 11.05.2021 12:25 # +2
Kiselyov zippers
ASD_77 11.05.2021 17:43 # +1
MAKAKA 11.05.2021 14:45 # +2