ВСЯ ПРАВДА О МАССИВАХ | СТРУКТУРЫ ДАННЫХ
Вставка
- Опубліковано 16 тра 2024
- Ссылка: go.sky.pro/alekos_java
Курс Java-разработчик для начинающих от опытных экспертов
Программирование в 3-х словах - это "алгоритмы над данными".
Без данных не было бы программирования, и от того, каким образом мы храним данные в памяти, зависит скорость работы с этими данными, а значит и скорость выполнения самой программы.
Многие структуры данных построены на других.
И у каждой структуры есть свои плюсы и минусы.
Начнем их рассмотрение с самого простого - с массивов и связанных списков.
Подписывайся в соц. сетях:
Телеграм - t.me/Alek_OS
ВК - alekos1
Яндекс Дзен - zen.yandex.ru/id/62220edf240e...
❤️ Поддержка канала:
Бусти - boosty.to/alekos
Юмани - yoomoney.ru/to/410011179144828
Патреон - / alekos1
✔️ Полезные ссылки:
Основы программирования - • КАК РАБОТАЕТ ПАМЯТЬ КО...
Полезно знать - • ЯЗЫКИ ПРОГРАММИРОВАНИЯ...
Алгоритмы и структуры данных - • УСКОРЬ СВОЙ КОД В МИЛЛ...
00:00 Введение
02:10 Массивы
03:08 РЕКЛАМА
05:10 Поиск в массиве
05:42 Вставка в массив
06:54 Удаление из массива
08:40 Связанные списки
09:44 Вставка в связанный список
11:10 Поиск + вставка в середину связанного списка
11:56 Удаление из связанного списка
Было бы круто от тебя видеть цикл видео про ООП, принципы правильного проектирования кода и подобное. Нравится как ты все визуализируешь, сразу все понятно становится
Рано или поздно все сводится к процедурному программированию.
@Пиво и приколы Перегорание
@@DocNight процессор сгорает?
@@DocNight оаоаоаоао. Как круто.
(...принципы правильного проектирования кода...) видео на 3 секунды. Их не существует... правильных. Они есть рзные, каждые служат своей цели. Проектирование кода... структурирование кода ещё туда-сюда.
Проектируют, обычно, системы, компоненты, модули методом декомпозиции функциональной, структурной, логической, физической, организационной.
2023 год, забудьте уже про ООП, в век поведенческих моделей -- дитя рожённое сумрачным гением Гарди Буча и Ива Якобса под конец 80-х. Имеет очень ограниченое применение, для прикладных систем.
ООП - как парадигма моделирования и описания реальных систем ещё более менее, но с оговорками. Но как принцип структурирования кода уже давно не выдерживает критики.
Как же круто подаётся материал! Прямо интересно смотреть и прямо сразу хочется ещё больше видео!
Низкий поклон автору за такие шедевры! Всегда с нетерпением жду новые видео!
Спасибо Алек за то, что делишься с нами своими знаниями
Великолепно изложено! Огромная благодарность за титанический труд!
Очень хорошая подача, сам до конца не знаю как устроены все структуры, поэтому жду продолжения!
Алекс, спасибо огромное, для меня твой канал просто как глоток свежего воздуха и огромное вдохновение. Моя жизнь и профессия давно устоялись, и работа моя не связана с программирование и IT. Сейчас изучаю Си просто для души, в школе увлекался бэйсиком и паскалем, благодаря этому поступил в институт без экзаменов после олимпиады, потом забросил, некогда было. Отсутствие необходимости изучать то что модно и в тренде, дает возможность изучать программирование так, как мне интересно а не требуется для обретения или смены профессии. Твой канал для меня просто находка, именно та информация которую я ищу. И пусть в современном мире низкоуровневое программирование не особо нужно, а все алгоритмы разложены по полочкам и изучены, пусть. Мне нравится именно корни и основы, и я буду программировать так, как раньше, экономя байты памяти, оптимизируя какие то задачи, что бы это могло запускаться на любом примитивном железе. Это самый кайф! Спасибо!
Красавчик, Алекс. Контент пушка, пили дальше. Будь уверен, благое дело делаешь, сил тебе, хорошей работы и здоровья, брат!
Благодарю Вас за ваш труд! Очень интересная подача материала. Не жалею, что нашёл этот канал.
Видос невероятный, монтаж на высоте как и объяснение, продолжай в том же духе!
Братан, хорошо, давай-давай вперёд! Контент вообще в кайф, красавчик! Можно вот этого и того почаще?
Как всегда афигенный контент! Всё раскладываешь по полочкам и показываешь наглядный пример! Если бы ты записал серию уроков по какому-либо ЯП или технологии, я бы в запой просмотрел всё!
Алек молодец ! всё очень понятно и без воды так держать!
Непревзойденно! Браво! Супер важное и сложное простым языком, понятной картинкой, стильно даже! Ты лучший!
Круто.
Я наконец-то стал что-то понимать!
Спасибо, друг!
Автору спасибо, за столь огромный труд!
Alek - Спасибо тебе за стольчудесный контент. Ты просто огромнейшый молодец, за столь краткий период времени ты уже сделал огромный вклад в жизни других людей, жаль что я больше не смогу видеть твои видео. 😁😗😉
Возвращаюсь к каждому видео по 3 раза, и как в хорошей книге нахожу что-то новое. Благодарю!
Просто мурашки от этих видосов, такой уже умничка 😍
Братан, хорош, давай-давай вперёд! Контент вообще в кайф, красавчик! Можно вот этого и того и почаще?
Спасибо, продолжай в том же духе!
Респект, брачо! всего тебе хорошего и побольше!
Спасибо за труд, но всё же как-то недостаточно. Я уже настроился и ожидал увидеть информацию о других стурктурах, как вдруг видео закончилось. Жду продолжения.
видео называется "вся правда о массивах"
Спасибо за выпуск!👍
Поиск в массиве имеет сложность O(n), это доступ к конкретному элементу по известному индексу O(1).
оговорочка
Но в отсортированном массиве O(log n) но не точно
Подача и полезность в одном видео - это редкость! красава
Случайно попал на видос! Подписываюсь) Автор крут!
Жду объяснение следующих структур СПС за видео.
Это просто щииииииииикарноооооооо! Топовый котент! Все очень наглядно) огромное спасибо за Ваш труд
Самый великолепный канал по програмированию
Огромное спасибо автору! Очень полезная информация
Подписался, спасибо большое! Как раз не хватает нормального материала на эту тему.
Очень круто. Добавляй в конце таблицу со сравнению сложностей пожалуйста
полезное дело делаешь, спасибо, продолжай!
Спасибо, очень крутые видео!
Продолжай в том же духе, очень круто!!
Графика кайф! Братан хорош, давай давай вперёд! Контент в кайф, можно ещё, вот этого и вон того? Вообще красавчик! Можно вот этого вот почаще?
Однозначно эти видео надо включать на уроках информатики... Всё доступно и понятно, а не нудятина которую преподают.
Круто, спасибо за контент.
Я кнш это всё знаю, но я не могу пропустить ни один твой видос. Они прекрасны😍
Спасибо за труды 👍👍👍
Большое спасибо!
Отличная подача... Спасибо.
Супер объяснение, кратко и четко
Спасибо за видео!
Я сейчас как раз изучаю массивы в ассемблере. Так как ассемблер самый низкоуровневый, то это видео для меня стает очень актуальным. Спасибо
gold in front of my eyes, very well done content. Thank you
Ха) моя курсовая работа с первого курса. Жаль , что видео вышли так поздно. Уж очень я страдал на с++ .
Спасибо за контент.
Реально так контент из которого, начинающим и даже программистам с опытом, нужно впитывать каждое слово.
Видео класс. Есть код для более глубокого ознакомления, тут же есть принципиальная картинка что происходит. Очень удобно.
А звуковое оформление вообще топ.
Контент просто огонь !!!
Спасибо за качественный контент! Подача материала отличная, сразу видно, что Автор знает о чём говорит.
Могу сказать пару слов о Связанных списках:
Преимущество Однонаправленного списка перед Двунаправленным в чуть меньшем потреблении памяти на каждый элемент списка и чуть более быстром выполнении некоторых функций.
На этом его преимущества заканчиваются, и проявляется множество НЕпреимуществ.
К примеру:
Поиск/Удаление/Вставка в Двунаправленном списке можно начать как с начала, так и с конца.
То-есть, если Index < Length / 2 = начинаем идти с Head-a к нужному элементу,
а если Index > Length / 2 с Tail-a назад к нужному элементу.
А в Однонаправленном списке тебе придётся идти всегда сначала.
По-этому, зачастую, Двунаправленные списки выигрывают у Однонаправленных.
Я промолчу о некоторых функциях, типа Реверса данных внутри списка или их Смещения (Не Nod-ов), там Однонаправленные списки сразу проигрывают...
Ура🎉 новое видео
спасибо, Брат!
пока что, структуры данных воспринимаю только в твоём изложении
Кстати, если тебе понравится такая тема, то предлагаю записать видео о двойной буферизации (когда используется два буфера для байтов данных). Это очень связано с тематикой канала, потому что такие алгоритмы помогают избежать например мерцания экрана. Но вообщем ты показываешь правильные вещи, респект и удачи в дальнейшем желаю.
Вот это реально, больше чем просто лайк
Отлично!
круто, спасибо!
Очень круто. За 13 минут благодаря крутому визуалу и грамотным объясниям вспомнил все, что в универе проходили чуть ли не целый семестр.
Было бы очень круто так же разобрать более сложные структуры, вроде тех же хеш-таблиц.
А ещё было бы полезно делать референсы на популярные языки, например, "массив в С - это чистый массив, а вот в плюсах - это двунаправленный связный список"
Ps не надо пожалуйста тригериться, про с/с++ я написал для примера и знаю что это не так
Сделай видео по алгоритмам! Понятно, что по хорошему оно займет не один час, но мне бы очень хотелось увидеть такое видео на твоём канале
Спасибо за видос! Расскажите пожалуйста про хеши.
Новый водосток подъехал, так ждал, так ждал
Привет 👋🏼
А ты можешь сделать видео о работе файловых систем?
Нужно продолжение.
Листы, Мапы, и т.д. и т.п. что и как устроено и как работает)
Ну о списках здесь было рассказано) Если не брать во внимание, что существуют списки реализованные поверх массивов
Афигенный ролик только бы вот были бы примеры с питоном, с++
Я делал такую базу, не подозревая, что именно о такой будут когда-то рассказывать. Нигде не учился. Пришел логично. Первый прототип базы был статический, но очень быстрый. И в момент, когда я не знал какой именно длинны будут некоторые текстовые поля, пришлось изобретать велосипед. Добавил ссылки. При удалении, информация просто не учитывалась. По факту она не удалялась. Ровно также вижу и работает Microsoft Access. Динамическая база данных при GOTO на нужный нам столбец работает медленней чем статическая, поскольку в статической можно просто умножить наш указатель на длину и мы точно попадем в начало нужной нам информации. А здесь нам уже нужно высчитывать из ссылки к ссылке пока не получим желаемую. Вначале я использовал только указатель "вперед". Но позже столкнулся с проблемой вставки информацию в середину и решил не раздвигать ячейки, не перезаписывать жёсткий диск за каждый раз, а это даже очень актуально при использовании SSD накопителя. По этому добавил указатель "назад" и это позволило мне добавлять значения в конец, но подавать пользователю это как будто данные находятся в середине. Чесно говоря не знаю что лучше прыжки или перезапись. Возможно найдутся люди умнее и заявят мол диск всегда перезаписывается. Не знаю что конкретно на физическом уровне там делается. Исходил из логики. Access будет удобней использовать, но там есть ограничения по объему памяти. Да и по скорости он проигрывает, но удобен в конструкторе, особенно на этапе создания, когда в процессе может понадобиться добавить новое поле в базу данных. А в своем движке приходится допилить функционал, чтоб поле безопасно добавить или удалить, чтоб при необходимости сжать базу (очистить от удаленных записей). Кстате, потом сделал еще один гибрид интересный где использовались два файла: один статический а другой динамический. Динамический только для текста, а в статическом были уже ссылки на точку входа информации в динамическом файле. Через 5 лет посмотрел на весь этот чудо код и офигел сколько времени было потрачено
Массивы и связанные списки это так сказать база, в книге «Грокаем алгоритмы» очень доходчиво объяснены.
Здравствуйте Алек. Я так понимаю, что когда то будет продолжение.. Дисциплина "Алгоритмы и структуры данных" интересная и большая.
По структурам: хэш-таблицы (с открытым, закрытым хэшированием), целая роща всяких деревьев с их самобалансировкой. Кстати, есть ещё "списки с пропусками". Это когда при движении прыгают через несколько узлов. При приближении к цели - постепенно через меньшее количество узлов. Т.е., там присутствуют узлы с разным количеством "next", как бы разной "высоты".
По алгоритмам: семейство сортировок . Начиная с трёх базовых O(n2). Потом сортировка Шелла, прочесыванием. Потом O(n*ln(n)) - Хоара, слиянием, пирамидальная. Ну, и мало знакомые - поразрядные (распределением) - для целых чисел . Для 4-хбайтных целых чисел - у поразрядной сортировки O(4n). Сравните: 4 и ln(n). Круче же, согласитесь! А почему то не не знают )) Ее на списках применять надо конечно. На массивах памяти много надо. Для строк есть запатентованная поразрядная: abc-sort.
Поиск подстроки в строке. Другими словами: слова или предложения в тексте. Или какой-либо последовательности (сигнатуры) в бинарном содержимом. Алгоритмы Кнута-Морриса-Пратта, Боуэра-Мура-Хорспула, Рабина-Карпа.
Это основные вещи, которые просто интересно знать!
@@404Negative Если быть принципиальным, то да. Вы правы. Однако в своем комментарии я делал упор на практическую составляющую. Программистов интересует именно это, они не математики. Даже в литературе встречается что-нибудь подобное как я написал, O(4n). В первом приближении это допустимо. После округления, по правилам асимптотической точности, O(4n) будет O(n). Это я знаю. Думаю и Вам было понятно, что я имею ввиду.
Я ведь акцентировал внимание на разнице между: 4 и ln(n). Т.е., буквально это выглядит так: T1=k*4*n и T2=k*ln(n)*n. Это конкретно время работы сортировки! Где k-некий коэффициент, одинаковый для разных сортировок при определенных условиях. Это один и тот же набор данных, одно и то же ЭВМ, с примерно одинаковой загруженностью операционной системы другими "посторонними" заданиями.
Для примера, у математиков все 3 базовые сортировки, конечно O(n2). Однако программист должен представлять, у "пузырька" и "извлечения(выбора)" количество сравнений пропорционально n2/2, а у "вставки (включения)" n2/4. Это конкретные цифры, которые определяют время сортировки в вашем приложении! На основе уже этого программист будет делать выбор.
Автору огромное спасибо за работу! А можешь подсказать что за фоновая музыка играет? Мне кажется она идеально подошла бы во время работы
Понравилось, круто
У списков есть ещё один весомый минус помимо дополнительного поля с указателем, жрущего память. Это malloc, который к тому же враппер к системному вызову alloc, который работает на VAD таблицах, которые также жрут память. Особенно когда элементы списка 10-50 байт в большинстве своём случаев, а alloc работает со страницами памяти по 4 килобайта. Это лютейший стресс для операционки. А некоторые операционки не умеют в принципе выделять память меньше страницы и получается что на элемент, в смысле на каждый элемент, размером в несколько байт улетает ровно 4 килобайта. Короче списки - величайшее зло и ошибка. Можно без них если чуть повнимательней отнестись к организации алгоритмов и структур данных.
Отличное замечание. И вообще, было бы неплохо автору указать как выделяться память ОС, из этого можно пересмотреть вообще подход к данным.
@@MrRastler Зачем писать велосипеды? Есть уже готовый список называется ArrayList. Если нужна скорость добавления данных то установите capacity правильное значение и arrayResize ни когда не произойдет. Если что элементы списка это 32 битные ссылки, поэтому смело можно задавать капасити в 8 мегабайтов, если точно знаете что у вас в списках может быть миллион элементов
Разве malloc может выделить 4кб памяти на КАЖДЫЙ элемент? Да, минимальный размер памяти, который можно "попросить" у операционной системы - это размер страницы виртуальной памяти. Далее уже задача libc при вызове malloc постараться задействовать куски этой страницы, и только если не получилось - запрашивать у операционной системы. Это уже не говоря о всяких jemalloc с кучей эвристик - thead-local буферы для обьектов фиксированной маленькой величины и тд
В крайней случае, можно выделять единым куском память память под 100, 200, 400 узлов списка и потом использовать их - реализовать pool allocator
Большим недостатком при этом будет частые промахи по кэшу - но это неизбежно
И все таки списки бывают довольно полезны - как без них реализовывать персистентные(ну даже персистентный стек) или lock-free (например Michael-Scott Queue) структуры?
Хорошо рассказал! И мультик наглядный! Пили есчо!
Я бы хотел попросить о видео по расчёту сложности алгоритмов 🙏
Спасибо!
Спасибо! Но мало :)
Я бы все таки рекомендую именовать поиск в массиве - доступом к элементу. Это не поиск в чистом виде. К примеру если взять код который на экране когда идет речь про поиск в списке - которое О(n) , где сверяется некая мифическая data, то такой код и на массиве будет за O(n) работать. Но это не отменяет крутости видоса!
Блин, ну ты и тему выбрал. Это всё я и так знал! :(
Повторение - мать учения
@@IDragonThunderI Можно было хотя бы про бинарные и лгбт деревья :)
Не смотрел, но уже понял, что топ
Контент шикарный! Спасибо за труд! И пожелание:
Интересно будет видео о процессах и потоках ОС. Как они создаются, хранятся, исполняются. Их параллельный запуск, приостановка, возобновление, взаимодействие. Что такое процесс? Есть ли предел количества потоков? Как чередуется исполнение потоков в CPU?
Открыть и почитать доку вообще не вариант?
@@diknik1148 чувак, что за наезд? Ты еще погуглить посоветуешь?
Это лишь было пожелание к новому контенту. Было бы здорово увидеть видео от автора с разбором этой темы, т.к. считаю что автор умеет хорошо разъяснять.
Наверное, окружающие люди считают тебя токсичным, как думаешь?
@@user-pi2my7ec1v, кстати, погуглить тоже неплохой совет.
А наезд мой в том, что твои вопросы не алгоритмические и не требуют визуализации для ответа.
Потом собеседуешь таких любителей просмотров видосов, а у них знания нет. Поверхностно глянут что-то в видео, а доки читать не удосуживаются.
Навык развития чтения документации нужно развивать, а не на ютуб идти по каждому чиху.
Спасибо за инфу! Стал не много умнее)
Спасиба бальшой ты очен памог
Сделай видео, как монтируешь видео.
Тонкость на которой любят валить на собеседованиях по C# и Java: массивы всегда являются ссылочным типом и следовательно память всегда будет выделяться в управляемой куче (за исключением unsafe кода), в стеке будет находиться указатель на выделенную область памяти. В C/C++ по умолчанию массив определяется в стеке, либо с помощью malloc определяется в куче.
Кольцевой однонаправленный список -> план эвакуации при пожаре.
Массивы: чёрт нас раскрыли, сваливаем
Помню в древних проектах создавали классы Array.
Я думал это из-за отсутствия std::vector.
Сейчас понимаю, что так работать с массивами проще.
Молю, сделай видео про процессы и потоки
Можно довольно несложным путём сделать, чтобы операция добавления и удаления в массив работала за O(1).
Для этого нужно при добавлении нового элемента в массив в ситуации, когда свободных "ячеек" нет - создавать новый массив не с размером N+1, а с размером N*2.
А при удалении - если количество оставшихся после удаления элементов в массиве меньше, чем половина длины - то нужно создать новый массив, размером в 2 раза меньше, и перенести туда все оставшиеся элементы.
Допустим, что у нас изначально массив размера 10, и мы добавляем туда 10 элементов. Тогда при добавлении первого элемента - у нас произойдёт создание нового массива, размером 20 + копирование 10 исходных элементов + добавление 1 элемента - т.е. 11 операций. При этом добавление остальных 9 элементов - займёт 9 операций.
В сумме получится, что добавление 10 элементов заняло 20 операций. А значит, добавление 1 элемента заняло, в среднем, 2 операции.
Если добавляем 100 элементов при изначальном количество 10 - то количество операций будет такое:
11 + 9 = 20 - чтобы добавить 10 элементов
21 + 19 = 40 - чтобы добавить ещё 20 элементов
41 + 39 = 80 - чтобы добавить ещё 40 элементов
81 + 29 = 110 - чтобы добавить оставшиеся 30 элементов.
Получается, суммарное количество операций - 250, что в среднем представляет из себя 2.5 операции на добавление 1 элемента.
При 1000 элементов - это будет так:
20 + 40 + 80 + 160 + 320 + 641 + 379 = 1640.
Получится, в среднем, 1.64 операции для добавления 1 элемента.
При 10000 элементов - это будет:
20 + 40 + 80 + 160 + 320 + 640 + 1280 + 2560 + 5121 + 4899 = 15120 - уже 1.512 операций для добавления одного элемента.
Если так продолжать - то в пределе количество операций для добавления одного элемента будет 1 - что и является асимптотикой O(1).
Чтобы было в среднем ровно 1 операция на добавление - нужно, чтобы на добавление M элементов нужно было M операций.
Худший вариант, который может быть - это когда у нас изначально 1 элемент в массиве.
В такой ситуации - добавление M элементов потребует 2+4+8+16+... операций - из которых половина уйдёт на дублирование массив, а половина - на добавление M элементов.
Количество шагов (n) можно рассчитать как логарифм по основание 2 от M, округлённый в нижнюю сторону + разница между M и этой суммой оставшихся элементов - но это значение не больше M - поэтому общее количество шагов можно считать как логарифм от M, округлённый в верхнюю сторону.
Сумма такой геометрической прогрессии - это 2*(2^n-1) =2^(n+1)-2. Учитывая, что n - количество шагов - это ⌈log_2_M⌉, получится, что сложность добавления M элементов - это O(2^(⌈log_2_M⌉+1)-2) = O(2*(M+1)-2) = O(2*M) = O(M) (я предполагаю, что, в худшем случае, округление вверх даст M+1).
Ну и отсюда вывод, что добавление одного элемента - O(1).
Немного кривоватое доказательство - но какое есть.
Примерно аналогичные рассуждения и для удаления.
Шок. Вся правда о массивах. Материал, запрещённый в официальной литературе по компьютерным технологиям. По существу, материал качественный, по-моему, подход автора серьёзен и строг :-)
по поводу поиска в массиве хочу сказать что O(1) это доступ на адрес так как в Си например *arr == arr[0] , получается что первый элемент это так же указатель на массив, и это облегчает найти нужный нам адрес но никак элемент который лежит в адресе, а поиск элемента уже O(n).
Только начал писать курсовую,на тему алгоритмов сортировки
Сначала лайк, потом просмотр))
Это конечно всё простенько, просто ужас сколько всего есть сложного в информатике, и поэтому становиться интересно. А самое главное, что математика тут играет ключевую роль, она помогает анализировать алгоритмы, описывать наш окружающий мир и тд. Поэтому самым главным инструментом программиста является именно математика.
Единственный канал где не проматываю рекламу, чтоб поддержать автора.
Интеграцию?😂
@@DolojUnynie да
огонь
Вообще, при удалении в обычном массиве можно менять удаляемый элемент с последним местами, и уменьшать размер на 1. Теряем строгий порядок (который, на самом деле, нужен не всегда), зато получаем удаление за О(1). Оптимизаций куча. По опыту, при всех плюсах, связный список нужен только в очень небольшом пуле задач.
Но это не будет удалением, а просто неиспользованием выделенной программе памяти
@@Dmytro-Tsymbaliuk а кто говорит что удаление в массиве это = освобождению памяти? В java и шарпе вообще отсутствует такое понятие как освобождение памяти. Там невозможно ни какими способами освободить память. Даже если прописать GC.Collect() это не дает гарантию что ваш обьект будет удален. Это легко проверить прописав в деструкторе лог. Вызов деструктора очень рандомная штука, сами майкософты запрещают в деструкторе класса что-то писать и за такой код бьют по рукам.
@@serhiis_ а причем тут вообще джава и шарп, когда речь о фундаментальных вещах? Совершенно не в тему
@@Dmytro-Tsymbaliuk Так разберись в фундаментальных вещах- Удаление из массива НЕ равно освобождение памяти. Это противоречит всем принципам программирования. Даже принципам в С++. Уже молчу про языки высокого уровня где освободить память невозможно
@@Dmytro-Tsymbaliuk Например возьми сишные функции работы со строками. Заметь ни одна сишная функция по операция со строками не удаляет память под строку. Хотя ты вроде обрезал строку слева или справо. И название функции как раз обрезка строки. Но по факту память та же самая диль указатель передвинулся вперед если удаление из начала строки. Или символ нуля перенесли если удаление из конца
Я изучал это на 1 курсе универа и реализовывал на C++
Ура
Привет, откуда ты получаешь эту информацию?
Скажите пожалуйста что за язык программирование в видео? Ради интереса.
11:55 айя-яй две стрелк из 3 ведут в 4)))
👍