Всё об указателях в C++ за 20 минут
HTML-код
- Опубликовано: 19 апр 2024
- Сегодня я расскажу о такой важной теме языка С++, как указатели.
Если это видео вам понравится, то обязательно ставьте лайки и подписывайтесь на канал: вам не сложно, а мне приятно.
Телеграм: t.me/mimocaketg
#C++ #указатели
На момент загрузки 604 подписчика 
Наука
Братан, хорош, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
точно такой же коммент видел
Последователь екстримкода
О, Вы тоже человек высокой культуры.
@@saikle_ Все мы...
Харош)))
спасибо большое, сильно помог мне осознать что вообще такое указатель и зачем ему ссылка. всего за пять минут обьяснил главное понятным языком
Бро, очень помогаешь! Все доходчиво и понятно, спасибо огромное!
Кто всё детство программировал на ассемблере указателей не боится.
5:10 Классическая путаница. Имя массива - это имя переменной которая имеет тип массива, а не тип указателя. Просто существует стандартное преобразование из типа массива в тип указателя. Считаю это важным проговаривать, а то начинающие начинают отождествлять эти типы.
8:33 Это требует не visual studio, это требует стандарт языка. "Subscribe!!" является типом const char[12], который нельзя неявно преобразовать в char*, но можно в const char*. Возможно заблуждение зарождается из практики языка C, где литерал строки действительно возвращает не константный массив, и из-за неявной возможности преобразования в указатель, думают, что сам литерал имеет тип указателя.
10:42 delete примененный к массиву вызовет деструктор только для первого элемента, но освободит всю память, аллоцированную под этот массив (хотя это, как я помню, implementation-defined behavior). Для массивов из объектов классов, которые сами что-то аллоцируют в куче, это утечка памяти всегда.
12:00 Прикольно было бы еще рассказать про квалификаторы const в таких случаях и их преобразование. Например, тип const int** pp не сможет указывать на int* p, в то время как const int* p может указывать на int x;
Класс! А я думал уже всё забыл. В универе на С/С++ начинал учиться прогать. Дз было - реализация вставки элемента в двусвязный список после определенного значения. До сих пор помню то чувство, когда "ура! работает! ". Удачи и спасибо за видео!
я не хочу показаться душнилкой, но что ты тут "все забыл", когда это буквально примитивная инфа. А про список - это вообще смешно.
Реально, такой классный канал, но так мало подписчиков(((
Сразу подписался. Продолжай!!!
Молодец, побольше такого!
как все чётко разжевал, не как мой препод🥲 спасибо тебе большое
Молодец! Спасибо за видео!
Спасибо ❤❤❤❤❤❤
Урааа
Посмотрев 20 минутное видео не поймешь как они работают. Практикуйтесь, друзья.
респект
Привет, я недавно начал изучать с++ и складывается впечатление что гайдов куча, говорят на нем можно сделать что угодно но когда ищу фактические примеры то осознаю что на нем это либо сложнее в 10 раз чем на любом другом яп либо вообще не делают. Когда у меня появилась идея изучать программирование я не имел конкретных предпочтений, но сейчас захотелось написать хотя бы самую простую 2д пиксельную игру и тут то я узнал что делать игры на с++ та еще жесть... Думаю теперь, а не зря я начал изучать именно его..
Выбери сразу свое направление, с++ заточен для всего, но на нем это сложнее.
Очевидно, что большинство фреймворков для тех же 2д игр написаны на с++, а ты используешь готовые функции, классы в другом языке.
С++ невозможно выучить полностью, так что выбери направление
ну с++ может для некоторых зашкварным показаться, но зато потом любой другой яп будет без проблем заходить. А вообще важно именно понимание того, что ты делаешь. Если ты понимаешь, как и что написать, то все можно на любом яп написать, другое дело, что на некоторых яп некоторые вещи удобнее делать
Если ты хочешь написать простую пиксельную 2д игру, то лучше всего подойдёт связка Python + библиотека Pygame, Godot с языком программирования GDScript(похож на python) / C# или Unity / Unity WebGL с C#
С/C++ лучше подходят для высокоскоростных или низкоуровневых(драйвера) продуктов, ещё с C легче изучать Язык Ассемблера
@@TherryYTдумаю если человек поработал с boost, корутинами, шаблонной магией и рекурсивным макросами, то плюсы он знает)
С++ просто мало что умеет из коробки. Есть куча библиотек и уже готовых решений. Надо лишь установить их и начать кодить
я что то не пойму, что сложного в указателях?
Го дальше
Godnota
Про выделенную память не совсем верно. Тут скорее прикол в отличии стека и кучи (heap). На куче можно выделить и гигабайт и 20 если это нужно программе, размер же стека сильно ограничен (по-моему около 2 мегабайтов для линукса). Также в операционной системе есть специальные средства более эффективной работы с кучей, например запись в SWAP разделы. Поэтому современные языки программирования, в том числе и C++ тяготеют к тому, чтобы хранить указать на объект в стеке, а сам объект в куче.
в куче достаточно медленная память, причем в раз 800 медленнее. Есть L1 L2 L3 L4 памяти, прочитай
и 20 гигов никто выделять не будет, оперативка средняя у людей 16 гигов
и работа с кучей не будет никогда более эффективная чем на стеке или еще более быстрой памяти.
то что указатели в стеке а объекты в куче это да, но все равно иногда можно чуть больше объекты запихнуть в стек , даже если они больше 8 байт.
в любом случае типо потом когда словишь ошибку переполнения стека, что нужно перенесешь в кучу, но его по факту надо под крышак загружать стек. все равно типо в стеке все статически и если ты не словил ошибку стека то потом не словишь.
Понятно. А зачем он нужен? Почему я не могу делать тоже самое с обычными переменными?
попробуй реализовать связанный список без указателей
Если коротко, то чтобы не засрать стек.
Если подробнее, то при вызове подпрограмм(процедуры, функции, методы) передаваемые переменные забрасываются в стек. Что в случае int'а мелочь, а вот в случае массива могут возникнуть проблемы. Особенно если используется рекурсия
Что именно "он"?
потому что это структура. на всех структурах самая быстрая работа в стеке, а хранение в куче, так как ты можешь записать допустим 10000000 пользователей в массив к примеру.
Если тебе надо через функцию изменять переменную вне неё, то изменять её надо через указатель. Если отправить в функцию саму переменную, то в её рамках ты будешь изменять только копию этой переменной, и если ты вернёшься, то отправленная переменная останется нетронутой.
Также полезно с массивами: из функции нельзя вернуть массив, поскольку если ты попытаешься, то ты вернёшь только указатель на неразмеченную память. Однако можно создать массив вне функции и отдать его ей, и она внесёт в него данные.
Ещё можно создавать мыссивы через malloc(), который возвращает указатель на выделенную память в куче, которая не имеет ограничений стековой памяти и не зависит от рамок функций.
Конечно, я говорю о Си, но я вполне уверен, что в C++ точно так же:
Неправильно декларировать указатели как:
int* ptr;
, поскольку если так декларировать несколько указателей одной строчкой:
int* ptr1, ptr2, ptr3;
, то на самом деле указателем будет только ptr1, а остальные - просто числами. Чтобы сделать их все указателями, надо делать:
int *ptr1, *ptr2, *ptr3;
Я сам не знаю, почему так, учитывая то, что по идее, указатель должен быть своим типом данных. Но, как я уже в сказал, это относится к Си, а C++ я не знаю.
Ну вообще да, если декларировать int* p1, p2, то это будет неправильно. Но если декларировать только один указатель, то компилятору будет все равно, где звёздочка, мне просто больше напиться писать int*
Глупость несусветная. Зачем ходить и повторять везде эти поверья? К тому же указатель не имеет никакого отношения к типу. Невежество порождает непонимание и всякие глупые поверья. И вместо того чтобы изучить тему люди бегают и доказывают необходимость всякой чуши.
Бро, фигню не неси. Статическая память в C / C++ это либо static переменные в скоупе (функции, класса и тд), либо то, что называется глобальными переменными (уже не важно static или нет, в данном случае ключевое слово влияет только на видимость переменной в других единицах трансляции).
То что ты назвал статикой - локальная / стековая память.
Почитай С. Прата, там подробно разъясняются эти темы.