Великолепные лекции и подача материала. Очень надеюсь, что дождемся курса выложенного курса по С, к которому иногда возвращается автор. Где учат и правильно читать сложные определения и многое другое.
Спасибо за лекцию! Аа, в C++ указатели на память вот такой ширины, Аа, в C++ шаблоны классов вот такой вышины, Аа, прострелянные ноги, Аа, нам с UB не по дороге, Аа, и no more попугай, Аа, и expired попугай.
Использую C++ на "бытовом" уровне: пишу инструменты для инженерных расчётов и моделирования, разные утилиты, -- и в основном "учил" язык по ошибкам и предупреждениям, выдаваемым при компиляции и исполнении. Теперь же, когда смотрю лекции, время от времени ловлю себя на мысленном восклицании: "Так во-от почему это так устроено!" :D Большое спасибо за познавательный канал!
Уже третью лекцию смотрю. И какой же прекрасный и умный лектор, которого приятно слушать. Спасибо за вашу работу и труд. PS моя учёба давно уже окончена и он не связанна с программированием, я вот просто люблю язык C++ 😊
Большое спасибо! 5:45 по поводу new[] дополню, что похоже обычно счетчик хранится только для типов с нетривиальным деструктором. Проверял на g++, clang++ и msvc, везде поведение совпало: Если перегрузить operator new[](size_t) и создать через него массив типа T1 с тривиальным деструктором, то будет вызван operator new[](sizeof(T1)*N). И то что вернет operator new будет возвращено вызвавшему коду. Если создать тип T2 с нетривиальным деструктором, то будет вызван new[](sizeof(T2)*N+sizeof(size_t)) и вызывающему коду будет возвращен указатель сдвинутый sizeof(size_t), а при вызове delete[] он будет сдвинут назад. Таким образом ни при перегрузке операторов new[], delete[], ни при их вызове про эту арифметику указателей можно не думать. В случае если тип имеет выравнивание и используется alignment new[] (вроде с C++17), то все аналогично, только будет резервироваться не на sizeof(size_t), а на требуемый alignment байт больше. Не знаю, отличается ли работа с дефолтными операторам new[]/delete[], но из этого примера я сделал для себя вывод, что наличие delete[] для массивов необходимо в первую очередь для вызова правильного количества деструкторов, а не для упрощения аллокации-деаллокации участков памяти. Хотя конечно одно другому наверное не мешает.
Если захотеть, то в пример где смотрели в дебагере в сырую память можно добавить массив интов или какой-то простой структуры, чтобы продемонстрировать отсутсвие этого счетчика. Во всяком случае в msvc в дебаге это так, в других случаях не проверял. Но можно оставить и без этого - в любом случае это такие технические детали, знание которых ничего не дает и на которые нельзя полагаться.
Константин, огромная благодарность за Ваши лекции! Подскажите, пожалуйста, на 29:12 вы приводите тезис о том, что в языке C вызов функции всегда rvalue. Однако в C++ у нас есть ссылки, поэтому мы можем вернуть ссылку на глобальный объект или выделенную в этой функции память, поэтому в C++ вызов функции может быть lvalue. А разве в C мы не можем вернуть указатель на глобальный объект или указатель на выделенную в этой функции память? Поставить вызов функции в левой части операции присваивания, а затем присвоить другой адрес данному указателю? Тогда вызов функции будет lvalue. Или я что-то неправильно понимаю? Заранее благодарю Вас за ответ!
Нет тогда всё равно rvalue. int *foo(); int p; foo() = &p; // не скомпилируется. Вот если разыменовать то да это уже будет lvalue. Но без разыменования само по себе не будет.
Константин, вы объяснили, почему конструкция const int &lx = 0 легальна с т.зр. компилятора и как это работает ( 19:40 ). Но не вполне понятно, в каких случаях может понадобиться в своей программе объявлять константные значения через ссылки или лучше такую форму никогда не применять и ограничиться простым синтаксисом объявления const int x = 0? Кажется, понял. Это используется, если мы возвращаем тяжеловесный объект T и хотим избежать копирования: const T x = foo() // здесь теоретически может быть копирование (хотя я проверил годболтом - нет копирования) const T &x = foo() // здесь его точно не будет и применяется livetime extension
Разработчики LLVM, например, предпочитают явно указывать static у функций вместо использования анонимных пространств имён, т.к. если есть *.cpp файл на 10000-30000 строк, то не всегда есть желание его прокручивать, чтобы увидеть что вот эта функция объявлена в анонимном пространстве имён, а глядя на static это всегда видно. Для классов, структур, перечислений выбора нет - только анонимные пространства имён. Здесь получается некоторая неконсистентность, но учитывая специфику проекта оправданная. В каких-нибудь проектах, где можно поддерживать разумный размер модулей трансляции и static в этом смысле не потребуется. В модульных тестах например можно весь файл теста загнать в анонимное пространство имён, чтобы сэкономить время при линковке.
Я тоже разработчик LLVM-based продукта (IGC). Именно эта часть coding style меня всегда несколько удивляла. Но разумное зерно тут конечно есть, static более локальная штука и он лучше дружит с хедерами.
Столяров это который считает всё что после C++98 злом? По идее должен нравиться либо его подход либо современный, который я излагаю. Оба они сложно совместимы.
@@tilir ну да, взгляды на вещи разные, но мне не мешает и там и там находить для себя полезное и получать удовольствие от этого) ну и наверное нельзя сказать, что он абсолютно не прав в своем непринятии нового
@@tilirКонстантин, для разрабочтика ваш подход, несомненно, лучше и больше подходит) У Столярова я, например, про низкоуровневые вещи читал - неплохо.
Константин, спасибо за лекцию! В ролике пару раз был упомянут дискорд - он только для студентом или это некая "общественная" конфа? Если последнее, хотелось бы присоединиться :)
Мне показалось что это так тупо, что даже смешно. И в контексте лекций эта шутка приобретает немного рекуррентный смысл - не понадобится ли еще одного мертвого попугая для случаев когда все плохо и нужно показать провисший указатель на провисший указатель? =) Как такового выражения pointing bird не встречал, так что как понял шутка основана на паралелли с названием класса охотничьих собак (легавые, pointing dogs, bird dogs), которые получили название из-за захарктерных повадок при выслеживании дичи. Есть например порода, которая так и называется - английский пойнтер. Соответсвенно если pointing dog приносит птицу, может ли это быть pointing bird?
22:00 Наверное, стоит всё-таки сказать, что это исключение из правил биндинга. [class.temporary] 6.12 В обычной ситуации ссылка бы продлила жизнь двойки. S{1;2} это не временный объект и даже не expression. Всё так?
Не вижу смысла это всё проговаривать. Основной мессадж такой: будьте аккуратны со связыванием ссылок, могут быть проблемы. Он, как мне кажется, доносится.
Цикл лекций очень нравится. Никак не влияющее на суть замечание. Я сам любитель Monty Python, колола ухо фраза "This is parrot no more". Поправлю, в оригинале: "This parrot ".
Именно поэтому такие функции никогда не перегружают. Вы можете их специализировать, но это другое: имя осталось тем же, вы просто руками провели инстанцирование для конкретного типа.
ua-cam.com/video/TQ5VPnKWqoY/v-deo.html Вы говорите, что после malloc и приведения указателя к типу Т объект как бы жив. Но разве это не UB? malloc не начинает жизнь объекта (не берем 20 стандарт), поэтому, насколько мне известно, любое обращение к такой сущности как к объекту - это неопределенное поведение. Или я не прав?
Я поэтому и выразился аккуратно. В последнем стандарте тоже не всё гладко. С другой стороны, если мы говорим о примитивных типах (int, double, ..) то после malloc/calloc они всегда были как бы вполне живы и готовы к использованию. Именно что "как бы" из-за неясного нормативного статуса. Но я тут себе позволяю эту вольность так как сразу же призываю всегда использовать new. А так да, надо будет обязательно снять deep dive лекцию по времени жизни, там бездны.
Спасибо большое за шикарные лекции! Пытаюсь проводить разбор полётов и на моменте в блоке про манглирование (45:29) не совсем понимаю о чём речь в примере, когда вы говорите мол, что в языке Си нет ничего неявного. Что значит "в функцию пришла ссылка, и мы кастуем эту ссылку к значению, и что мы кастуем, указатель или значение под ссылкой? Мы не знаем." В предыдущей лекции мы уяснили, что когда объект передаётся по ссылке в функцию, на уровне ассемблера эта ссылка существует, как указатель, а на уровне синтаксиса языка си она существует, как другое имя для объекта снаружи, ну или, как уже разыменованный указатель на объект снаружи (и с членами ссылками класса происходит ровно то же самое). И если внутри этой ф-ции мы хотим начать относиться к значению под ссылкой, как к чему-то другому, чем оно не является, то, насколько я понимаю, мы создаём переменную типа этого "чего-то другого", и присваиваем ей скастованное в тип "этого чего-то другого" значение ссылки (без всяких ref и deref). А если мы хотим относиться непосредственно к исходному объекту, как к чему-то другому внутри этой ф-ции, то мы создаём, например, переменную-указатель на тип "этого-чего-то-другого" и приравниваем её к результату каста в указатель на "это что-то другое" &-этой ссылки, и работаем дальше с указателем. В чём именно здесь состоит неявность при касте?
> на уровне ассемблера эта ссылка существует, как указатель Она не обязана. Это всего лишь распространённый способ представить вещи. В языке C вы передаёте настоящий указатель, состоящий из настоящих бит и показывающий на какую-то локацию в памяти. Ссылка это просто другое имя для объекта, её побитовое представление не определено.
@@tilir угу. Т.е. неявность состоит в том, что при передаче аргумента в ф-цию по ссылке, побитовое представление этой ссылки внутри ф-ции для программиста не определено/скрыто. Понятно. Спасибо Вам ещё раз. И с наступающим!
На 42:00 нельзя воспользоваться _Generic для выбора нужной нам функции? (но всё равно 2 функции написать надо) Или я что-то путаю и его совсем не в таких ситуациях применять надо?
Ох. Вы не хотите использовать генерики с указателями, поверьте. Там очень неочевидное поведение. Например генерик от строкового литерала матчит обычный char* и т.д.
Здравствуйте! Спасибо за лекции. У меня вопрос насчет 34:01. Разве 0xbeec30 + 0xa0 (20 * 8) == beec80? То есть как будто указатель смещается лишь на половину длины массива, если я правильно понимаю.
@@ivankorotkov2563 а, все, и правда. Меня спутал sizeof(ptr), а он всегда равен длине машинного слова. Про это я забыл. Спасибо, что вывели на нужный путь!
30:00 - вернулся сюда, потому что возник чисто философский вопрос: Корректно ли считать, что lvalue - значение с семантикой хранения (storage)? Т.е. компилятор как бы обязан сохранять такое значение дольше, чем до конца полного выражения (что и отличает lvalue от временного rvalue). Соответственно, есть какое-то расположение (location) для хранения (storage). Данная мысль возникла, потому что есть "storage class specifiers", справедливые для lvalue. К слову, мне как-то тяжело представить, например, static-rvalue...
@@tilir Я сформулирую чуть иначе: Если по тайм-коду в Вашей фразе заменить "адрес" на "storage" - это корректно? P.S. я подразумевал не "значение", а "value category".
Да я думаю там и "адрес"-то я говорю не вполне точно, а просто чтобы создать понимание. Если говорить точно, то: A glvalue is an expression whose evaluation determines the identity of an object or function. An lvalue is a glvalue that is not an xvalue. The result of a glvalue is the entity denoted by the expression. И в общем это всё, что мы знаем. Термин identity не определяется, стандарт не обязан быть машиночитаемым, его для людей пишут. А дальше в силу понимания можно спекулировать насчёт storage (а почему не быть storage у result object для prvalue?), адресов и всего остального. Но всё это -- скорее дидактические уловки.
@@tilir про storage - просто как-то удобнее восприятие (storage location, storage class). Например, на cppreference для Си есть вот такое: Colloquially known as rvalues, non-lvalue object expressions are the expressions of object types that do not designate objects, but rather values that have no object identity or *storage location*. The address of a non-lvalue object expression cannot be taken. ... - Я задумался, насколько корректно обратное, причём для Си++. Т.к. я относительно недавно начал изучать Си++, возникают подобные вопросы, нужные для какого-то базового восприятия и понятного объяснения, потому что тема запутанная; Её тяжело понять, но можно "прочувствовать".
Я ещё на тысячу не выложил =) На самом деле сейчас пока выкладка каждую неделю, нет смысла разбавлять. Зимой как начнётся сессия, начнём дополнительную программу...
4:00 int *t = new Widget; int *p = new Widget[5]; Даже если есть возможность написать такой класс Widget, чтобы это компилировалось, то к обсуждаемому предмету это явно отношения не имеет
Очень хорошее изложение! Лектору респект! Немного выбешивает "си плас плас", когда есть нормальное русское слово "плюс". И для namespace std "студ" или "стюд"? Что это за фигня! Причем сам лектор в один из моментов перешел на ожидаемое "'эстэдэ".
В программировании принято передавать имена собственные транскрипцией: "Си-шарп" а не "Си-диез", "Джава", а не "Ява" и т.д. Не понимаю почему должно быть исключение для "Си-плас-плас". К "эстэдэ" лучше не привыкать ещё и по практичной причине. Как программистам, студентам придётся разговаривать о рабочих вопросах в основном на английском, а выскакивает оно на автомате и ваши нерусские коллеги вас просто не будут понимать. Мне пришлось долго переучиваться и то иногда какое-нибудь "гэцэцэ" вместо gcc проскочит. Лучше сразу учить произносить термины так как это принято во всём мире.
@@aleonaxel то что мы очень уважаем господина Ван Ырда за его блестящие доклады по атомикам не добавляет ему прав влиять на естественный язык. Общепринято говорить "студ". Возьмите случайным образом десять докладов с CppCon и вы попадёте в десять. Вот это и имеет значение. А личное мнение члена комитета -- не имеет. Он же не в комитете по стандартизации английского сидит. Да и нет такого комитета.
Великолепные лекции и подача материала. Очень надеюсь, что дождемся курса выложенного курса по С, к которому иногда возвращается автор. Где учат и правильно читать сложные определения и многое другое.
Так я выложил на этом же канале.
Поймал себя на мысли - третий день смотрю лекции по C++ чтобы отдохнуть после работы. Обалдеть. Спасибо большое за лекции, они крайне интересные.
Такая же история. А я даже не программист 😮
Спасибо за лекцию!
Аа, в C++ указатели на память вот такой ширины,
Аа, в C++ шаблоны классов вот такой вышины,
Аа, прострелянные ноги,
Аа, нам с UB не по дороге,
Аа, и no more попугай,
Аа, и expired попугай.
Как же круто! Спасибо Вам за лекции! Они делают меня более образованным разработчиком!)
Использую C++ на "бытовом" уровне: пишу инструменты для инженерных расчётов и моделирования, разные утилиты, -- и в основном "учил" язык по ошибкам и предупреждениям, выдаваемым при компиляции и исполнении. Теперь же, когда смотрю лекции, время от времени ловлю себя на мысленном восклицании: "Так во-от почему это так устроено!" :D
Большое спасибо за познавательный канал!
Уже третью лекцию смотрю. И какой же прекрасный и умный лектор, которого приятно слушать. Спасибо за вашу работу и труд. PS моя учёба давно уже окончена и он не связанна с программированием, я вот просто люблю язык C++ 😊
Большое спасибо!
5:45 по поводу new[] дополню, что похоже обычно счетчик хранится только для типов с нетривиальным деструктором. Проверял на g++, clang++ и msvc, везде поведение совпало:
Если перегрузить operator new[](size_t) и создать через него массив типа T1 с тривиальным деструктором, то будет вызван operator new[](sizeof(T1)*N). И то что вернет operator new будет возвращено вызвавшему коду.
Если создать тип T2 с нетривиальным деструктором, то будет вызван new[](sizeof(T2)*N+sizeof(size_t)) и вызывающему коду будет возвращен указатель сдвинутый sizeof(size_t), а при вызове delete[] он будет сдвинут назад. Таким образом ни при перегрузке операторов new[], delete[], ни при их вызове про эту арифметику указателей можно не думать.
В случае если тип имеет выравнивание и используется alignment new[] (вроде с C++17), то все аналогично, только будет резервироваться не на sizeof(size_t), а на требуемый alignment байт больше.
Не знаю, отличается ли работа с дефолтными операторам new[]/delete[], но из этого примера я сделал для себя вывод, что наличие delete[] для массивов необходимо в первую очередь для вызова правильного количества деструкторов, а не для упрощения аллокации-деаллокации участков памяти. Хотя конечно одно другому наверное не мешает.
Про перегрузку будет чуть позже, но наблюдения очень интересные, спасибо.
Если захотеть, то в пример где смотрели в дебагере в сырую память можно добавить массив интов или какой-то простой структуры, чтобы продемонстрировать отсутсвие этого счетчика. Во всяком случае в msvc в дебаге это так, в других случаях не проверял.
Но можно оставить и без этого - в любом случае это такие технические детали, знание которых ничего не дает и на которые нельзя полагаться.
Спасибо большое за лекции! 🙂
Посмотрел про манглирование. Вопрос про API в ООП снят. Теперь я понял почему понятие перегрузки методов невозможен в Си.
Великолепно
оч. крутой урок!
Константин, огромная благодарность за Ваши лекции!
Подскажите, пожалуйста, на 29:12 вы приводите тезис о том, что в языке C вызов функции всегда rvalue. Однако в C++ у нас есть ссылки, поэтому мы можем вернуть ссылку на глобальный объект или выделенную в этой функции память, поэтому в C++ вызов функции может быть lvalue. А разве в C мы не можем вернуть указатель на глобальный объект или указатель на выделенную в этой функции память? Поставить вызов функции в левой части операции присваивания, а затем присвоить другой адрес данному указателю? Тогда вызов функции будет lvalue. Или я что-то неправильно понимаю? Заранее благодарю Вас за ответ!
Нет тогда всё равно rvalue.
int *foo();
int p;
foo() = &p; // не скомпилируется.
Вот если разыменовать то да это уже будет lvalue. Но без разыменования само по себе не будет.
Константин, вы объяснили, почему конструкция const int &lx = 0 легальна с т.зр. компилятора и как это работает ( 19:40 ).
Но не вполне понятно, в каких случаях может понадобиться в своей программе объявлять константные значения через ссылки
или лучше такую форму никогда не применять и ограничиться простым синтаксисом объявления const int x = 0?
Кажется, понял. Это используется, если мы возвращаем тяжеловесный объект T и хотим избежать копирования:
const T x = foo() // здесь теоретически может быть копирование (хотя я проверил годболтом - нет копирования)
const T &x = foo() // здесь его точно не будет и применяется livetime extension
Разработчики LLVM, например, предпочитают явно указывать static у функций вместо использования анонимных пространств имён, т.к. если есть *.cpp файл на 10000-30000 строк, то не всегда есть желание его прокручивать, чтобы увидеть что вот эта функция объявлена в анонимном пространстве имён, а глядя на static это всегда видно. Для классов, структур, перечислений выбора нет - только анонимные пространства имён. Здесь получается некоторая неконсистентность, но учитывая специфику проекта оправданная. В каких-нибудь проектах, где можно поддерживать разумный размер модулей трансляции и static в этом смысле не потребуется. В модульных тестах например можно весь файл теста загнать в анонимное пространство имён, чтобы сэкономить время при линковке.
Я тоже разработчик LLVM-based продукта (IGC). Именно эта часть coding style меня всегда несколько удивляла. Но разумное зерно тут конечно есть, static более локальная штука и он лучше дружит с хедерами.
Подскажите, можно ли где- то взять задачки по с++? Хочется порешать, попрактиковаться
Я читал Столярова, и думал, что это лучшее, что есть по программированию, но теперь я определенно нашел материал круче!!!
Столяров это который считает всё что после C++98 злом? По идее должен нравиться либо его подход либо современный, который я излагаю. Оба они сложно совместимы.
@@tilir ну да, взгляды на вещи разные, но мне не мешает и там и там находить для себя полезное и получать удовольствие от этого) ну и наверное нельзя сказать, что он абсолютно не прав в своем непринятии нового
@@tilirКонстантин, для разрабочтика ваш подход, несомненно, лучше и больше подходит) У Столярова я, например, про низкоуровневые вещи читал - неплохо.
Константин, спасибо за лекцию! В ролике пару раз был упомянут дискорд - он только для студентом или это некая "общественная" конфа? Если последнее, хотелось бы присоединиться :)
Общественная. Поищите инвайт на вкладке коммьюнити.
26:30 Есть же отличный термин -- вырождение. Прямая вырождается в точку, ссылка вырождается в int.
Кстати да. Прекрасная идея!
"Кроме того мы знакомимся с мёртвым попугаем." :D
Мы его ещё неоднократно увидим =)
- Что это?
- Указательная птица.
ua-cam.com/video/1jprsqUKE4Q/v-deo.html
@@ivankorotkov2563 а ты хорош. Надо на заметку взять.
Dangling pointing bird. Не знал, забавная параллель =)
Мне показалось что это так тупо, что даже смешно. И в контексте лекций эта шутка приобретает немного рекуррентный смысл - не понадобится ли еще одного мертвого попугая для случаев когда все плохо и нужно показать провисший указатель на провисший указатель? =)
Как такового выражения pointing bird не встречал, так что как понял шутка основана на паралелли с названием класса охотничьих собак (легавые, pointing dogs, bird dogs), которые получили название из-за захарктерных повадок при выслеживании дичи. Есть например порода, которая так и называется - английский пойнтер. Соответсвенно если pointing dog приносит птицу, может ли это быть pointing bird?
22:00
Наверное, стоит всё-таки сказать, что это исключение из правил биндинга.
[class.temporary] 6.12
В обычной ситуации ссылка бы продлила жизнь двойки. S{1;2} это не временный объект и даже не expression. Всё так?
Не вижу смысла это всё проговаривать. Основной мессадж такой: будьте аккуратны со связыванием ссылок, могут быть проблемы. Он, как мне кажется, доносится.
Добрый день. Спасибо за материал.
Зачем делать плохие бинды последними в иерархии разрешения перегрузки, если это вообще ошибка компиляции?
Я не уверен в ответе, т.к. речь о мотивациях, но я полагаю их проще сделать viable и пусть потом упадут, чем исключать.
Цикл лекций очень нравится. Никак не влияющее на суть замечание. Я сам любитель Monty Python, колола ухо фраза "This is parrot no more". Поправлю, в оригинале: "This parrot ".
Классные лекции, а есть ли плейлист с лекциями первого курса? Большое спасибо!
Да есть, в него сейчас идёт выкладка. Посмотрите на канале в списке плейлистов.
1:07:40 std::less std::equal_to std::swap std::hash
Именно поэтому такие функции никогда не перегружают. Вы можете их специализировать, но это другое: имя осталось тем же, вы просто руками провели инстанцирование для конкретного типа.
Страшная функция на 35:48 -- это signal()? Хотя подозреваю, что похожих много)
ua-cam.com/video/TQ5VPnKWqoY/v-deo.html
Вы говорите, что после malloc и приведения указателя к типу Т объект как бы жив. Но разве это не UB? malloc не начинает жизнь объекта (не берем 20 стандарт), поэтому, насколько мне известно, любое обращение к такой сущности как к объекту - это неопределенное поведение. Или я не прав?
Я поэтому и выразился аккуратно. В последнем стандарте тоже не всё гладко. С другой стороны, если мы говорим о примитивных типах (int, double, ..) то после malloc/calloc они всегда были как бы вполне живы и готовы к использованию. Именно что "как бы" из-за неясного нормативного статуса. Но я тут себе позволяю эту вольность так как сразу же призываю всегда использовать new.
А так да, надо будет обязательно снять deep dive лекцию по времени жизни, там бездны.
Да, думаю такая лекция была бы очень интересной! Будем ждать!
Спасибо большое за шикарные лекции! Пытаюсь проводить разбор полётов и на моменте в блоке про манглирование (45:29) не совсем понимаю о чём речь в примере, когда вы говорите мол, что в языке Си нет ничего неявного.
Что значит "в функцию пришла ссылка, и мы кастуем эту ссылку к значению, и что мы кастуем, указатель или значение под ссылкой? Мы не знаем."
В предыдущей лекции мы уяснили, что когда объект передаётся по ссылке в функцию, на уровне ассемблера эта ссылка существует, как указатель, а на уровне синтаксиса языка си она существует, как другое имя для объекта снаружи, ну или, как уже разыменованный указатель на объект снаружи (и с членами ссылками класса происходит ровно то же самое).
И если внутри этой ф-ции мы хотим начать относиться к значению под ссылкой, как к чему-то другому, чем оно не является, то, насколько я понимаю, мы создаём переменную типа этого "чего-то другого", и присваиваем ей скастованное в тип "этого чего-то другого" значение ссылки (без всяких ref и deref).
А если мы хотим относиться непосредственно к исходному объекту, как к чему-то другому внутри этой ф-ции, то мы создаём, например, переменную-указатель на тип "этого-чего-то-другого" и приравниваем её к результату каста в указатель на "это что-то другое" &-этой ссылки, и работаем дальше с указателем.
В чём именно здесь состоит неявность при касте?
> на уровне ассемблера эта ссылка существует, как указатель
Она не обязана. Это всего лишь распространённый способ представить вещи.
В языке C вы передаёте настоящий указатель, состоящий из настоящих бит и показывающий на какую-то локацию в памяти.
Ссылка это просто другое имя для объекта, её побитовое представление не определено.
@@tilir угу. Т.е. неявность состоит в том, что при передаче аргумента в ф-цию по ссылке, побитовое представление этой ссылки внутри ф-ции для программиста не определено/скрыто.
Понятно.
Спасибо Вам ещё раз. И с наступающим!
37:18 что значит, ptr_to_fref bar - в ней ведь два параметра
ptr_to_fref это возвращаемый тип функции bar.
Файл overload.cc
#ifndef N14
int foo(...) { return 21; }
#endif
Тут так и задумано возвращать 21 а не 14? Для N15 то же самое
Это я неаккуратно обернул макросом. Имелось в виду N21. С другой стороны есть ли разница, лишь бы различались...
На 42:00 нельзя воспользоваться _Generic для выбора нужной нам функции? (но всё равно 2 функции написать надо) Или я что-то путаю и его совсем не в таких ситуациях применять надо?
Ох. Вы не хотите использовать генерики с указателями, поверьте. Там очень неочевидное поведение. Например генерик от строкового литерала матчит обычный char* и т.д.
Здравствуйте! Спасибо за лекции. У меня вопрос насчет 34:01. Разве 0xbeec30 + 0xa0 (20 * 8) == beec80? То есть как будто указатель смещается лишь на половину длины массива, если я правильно понимаю.
Массив интов имеет размер 20*4, т.к. sizeof(int) = 4. То есть нужно прибавлять 20*4, а не 20*8. 0xbeec30 + 0x50 (20*4) = 0xbeec80 и все сходится.
@@ivankorotkov2563 а, все, и правда. Меня спутал sizeof(ptr), а он всегда равен длине машинного слова. Про это я забыл. Спасибо, что вывели на нужный путь!
@@incrediblesaint5020 не длине машинного слово, а ширине адресной шины в байтах
30:00 - вернулся сюда, потому что возник чисто философский вопрос:
Корректно ли считать, что lvalue - значение с семантикой хранения (storage)?
Т.е. компилятор как бы обязан сохранять такое значение дольше, чем до конца полного выражения (что и отличает lvalue от временного rvalue).
Соответственно, есть какое-то расположение (location) для хранения (storage).
Данная мысль возникла, потому что есть "storage class specifiers", справедливые для lvalue. К слову, мне как-то тяжело представить, например, static-rvalue...
Нет, lvalue это не свойство значения. Это свойство выражения.
@@tilir Я сформулирую чуть иначе:
Если по тайм-коду в Вашей фразе заменить "адрес" на "storage" - это корректно?
P.S. я подразумевал не "значение", а "value category".
Да я думаю там и "адрес"-то я говорю не вполне точно, а просто чтобы создать понимание.
Если говорить точно, то:
A glvalue is an expression whose evaluation determines the identity of an object or function.
An lvalue is a glvalue that is not an xvalue.
The result of a glvalue is the entity denoted by the expression.
И в общем это всё, что мы знаем. Термин identity не определяется, стандарт не обязан быть машиночитаемым, его для людей пишут. А дальше в силу понимания можно спекулировать насчёт storage (а почему не быть storage у result object для prvalue?), адресов и всего остального. Но всё это -- скорее дидактические уловки.
@@tilir про storage - просто как-то удобнее восприятие (storage location, storage class).
Например, на cppreference для Си есть вот такое:
Colloquially known as rvalues, non-lvalue object expressions are the expressions of object types that do not designate objects, but rather values that have no object identity or *storage location*. The address of a non-lvalue object expression cannot be taken.
...
- Я задумался, насколько корректно обратное, причём для Си++.
Т.к. я относительно недавно начал изучать Си++, возникают подобные вопросы, нужные для какого-то базового восприятия и понятного объяснения, потому что тема запутанная; Её тяжело понять, но можно "прочувствовать".
1:01:14
не очень понятно, о чем будут говорить, но надеюсь, что лектор напомнит
SFINAE - substitution failure is not an error
ээх, почему хорошие преподаватели всегда где-то, но не у тебя в учебке
Константин, спешал на 2000 подписчиков будет?
Я ещё на тысячу не выложил =)
На самом деле сейчас пока выкладка каждую неделю, нет смысла разбавлять. Зимой как начнётся сессия, начнём дополнительную программу...
@@tilir будем надеяться, что к тому времени подписчиков будет еще в несколько раз больше :)
Убитые котята, мертвые попугаи, я что сюда грустить пришла...
Блина, теперь еще и цветы...
Я сразу предупредил что будет грустненько. Но уже скоро я исправлюсь -- записана и монтируется лекция по инициализации, веселая и жизнерадостная ))
@@tilir Хехе, ждем :)
23:21 S *p = new S{1, 2};
Явно созданный конструктор копирования исправит ситуацию.
Хотя получается, что в данном случае их понадобиться два. Или один в том случае, если использовать универсальную ссылку и std::forward. Кажется так.
В какой программе лектор отладку программы делает и запускает их?
В консоли.
4:00
int *t = new Widget;
int *p = new Widget[5];
Даже если есть возможность написать такой класс Widget, чтобы это компилировалось, то к обсуждаемому предмету это явно отношения не имеет
Что значит "даже если"? Это любой тип, даже int. Это компилируется всегда: godbolt.org/z/YoEdq6aeG
@@tilirсейчас вы прислали корректный код, но на слайде слева int*, а справа Widget и такое не компилируется.
@@ll-ib5jr а я понял. Это опечатка. Имелся в виду widget*.
как же сложно все это мать его заногу
Да пердоллинг обычный. В итоге будешь писать на цпп11, если дело дойдёт.
Очень хорошее изложение! Лектору респект!
Немного выбешивает "си плас плас", когда есть нормальное русское слово "плюс".
И для namespace std "студ" или "стюд"? Что это за фигня! Причем сам лектор в один из моментов перешел на ожидаемое "'эстэдэ".
В программировании принято передавать имена собственные транскрипцией: "Си-шарп" а не "Си-диез", "Джава", а не "Ява" и т.д. Не понимаю почему должно быть исключение для "Си-плас-плас".
К "эстэдэ" лучше не привыкать ещё и по практичной причине. Как программистам, студентам придётся разговаривать о рабочих вопросах в основном на английском, а выскакивает оно на автомате и ваши нерусские коллеги вас просто не будут понимать. Мне пришлось долго переучиваться и то иногда какое-нибудь "гэцэцэ" вместо gcc проскочит. Лучше сразу учить произносить термины так как это принято во всём мире.
@@tilir ua-cam.com/video/RVvVQpIy6zc/v-deo.html Чувак из комитета утверждает, что все рано или поздно должны перейти на "стэндарт" вместо "студ" ))
@@aleonaxel то что мы очень уважаем господина Ван Ырда за его блестящие доклады по атомикам не добавляет ему прав влиять на естественный язык.
Общепринято говорить "студ". Возьмите случайным образом десять докладов с CppCon и вы попадёте в десять. Вот это и имеет значение. А личное мнение члена комитета -- не имеет. Он же не в комитете по стандартизации английского сидит. Да и нет такого комитета.