47:00 Константин, здесь явно UB. Предположим, что в deallocate пришел указатель T *, который в действительности указывает на объект типа T. Тогда reinterpret_cast(ptr) даст указатель node *, который всё ещё указывает на объект типа T, строго по правилам преобразования указателей ([basic#compound-5], [expr.reinterpret.cast#7], [expr.post#expr.static.cast-14]). Да и в принципе, если значение указателя не "указывает на что-то, pointer-interconvertible с node", оно останется неизменным, только тип поменяется. В следующей строке (88) мы сразу делаем обращение к объекту (node), не являющегося type-accessible [expr#basic.lval-11], получая UB Первым шагом к исправлению было бы заменить aligned_storage (который с С++23 deprecated), на T. Тогда, если гарантировать, что в deallocate приходят только указатели, выделенные аллокатором, благодаря pointer-interconvertible сможем получать указатель на node Вторым шагом было бы заменить выделение блока памяти на массив из node, чтобы сразу начать жизнь объектов node. Это просто сделать, добавив полю next инициализатор, сделав union implicit-lifetime type Скорее всего нужно будет сделать еще что, но для этого нужно более подробно шерстить стандарт. Ну и разумеется, всё ещё ждём завоза в компиляторы std::start_lifetime_as и std::is_implicit_lifetime
Я правильно понимаю, что можно для небольших размеров контейнера можно сделать кастомную арену и кастомные указатели размером 8-16-32 бита? На каких-нибудь списках и деревьях, где указатели занимают много места, так можно неплохо сэкономить память:)
Константин, спасибо за лекции! Можете, пожалуйста , разъяснить почему надо использовать aligned_storage а не просто написать union node { node *next; T storage; };
Использование aligned_storage яснее выражает что мы хотим неинициализированное место для placement new. Использование просто T может вызвать иллюзию что мы и правда хотели бы хранить там T по значению.
А на вопрос про gcc и list на 56:00 есть ответ? Ведет себя очень странно, когда вызывается list.remove gcc создает аллокатор инта из аллокатора ноды, потом создает аллокатор ноды из аллокатора инта, и видимо после ремува удаляет аллокатор с вынутой нодой.
51:29 У нас всегда условие this == &other будет true, мы в операторе сравнения это явно указали, и мы никогда ничего не мувнем. Может быть лучше листы сравнивать?
Он не столько холиварный сколько мы к нему ещё вернемся. Если аллокатор часть типа то ответ очень простой: да разные типы значит разные объекты. А вот если не часть типа, то.... (тут клиффхэнгер).
1:10:00 Константин, правильно ли я понимаю, что здесь срабатывает "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule" из С++20 и "The result of the search is the declaration set of S(M,T). If it is an invalid set, the program is ill-formed. If it differs from the result of a search in T for M in a complete-class context ([class.mem]) of T, the program is ill-formed, no diagnostic required." ([basic.lookup#class.member.lookup-6]) из С++23? Если это так, за что же балл обещался?)
@@alex_s_ciframi только если нужна особая обработка для a=a. Здесь проблем с таким присваиванием не будет. Ну и вообще хороший copy-assignment это обычно copy-and-swap где такая проверка тоже не нужна.
28:00 но ведь если в 98 году в аллокаторе были запрещены иные typedef'ы, то как тогда они должны были возвращать far pointer'ы вектору? для них ведь отдельный тип заведён, а вы как раз раньше говорили, что их поддержка это единственная причина, по которой Степанов их изобрёл
23:40 а можете, пожалуйста, объяснить зачем это вообще было нужно добавлять? разве стандарт предусматривает какие-то другие способы вызвать конструктор? у меня есть догадка, что placement new не работал с far pointer'ами, но я не уверен насколько эта догадка верна
Как всегда - ясно, просто и великолепно
47:00 Константин, здесь явно UB. Предположим, что в deallocate пришел указатель T *, который в действительности указывает на объект типа T. Тогда reinterpret_cast(ptr) даст указатель node *, который всё ещё указывает на объект типа T, строго по правилам преобразования указателей ([basic#compound-5], [expr.reinterpret.cast#7], [expr.post#expr.static.cast-14]). Да и в принципе, если значение указателя не "указывает на что-то, pointer-interconvertible с node", оно останется неизменным, только тип поменяется. В следующей строке (88) мы сразу делаем обращение к объекту (node), не являющегося type-accessible [expr#basic.lval-11], получая UB
Первым шагом к исправлению было бы заменить aligned_storage (который с С++23 deprecated), на T. Тогда, если гарантировать, что в deallocate приходят только указатели, выделенные аллокатором, благодаря pointer-interconvertible сможем получать указатель на node
Вторым шагом было бы заменить выделение блока памяти на массив из node, чтобы сразу начать жизнь объектов node. Это просто сделать, добавив полю next инициализатор, сделав union implicit-lifetime type
Скорее всего нужно будет сделать еще что, но для этого нужно более подробно шерстить стандарт. Ну и разумеется, всё ещё ждём завоза в компиляторы std::start_lifetime_as и std::is_implicit_lifetime
Мне нравится использование вами слова "явно" в задачке которую не могут решить поколения магистрантов. Явно, ага ))
Я правильно понимаю, что можно для небольших размеров контейнера можно сделать кастомную арену и кастомные указатели размером 8-16-32 бита? На каких-нибудь списках и деревьях, где указатели занимают много места, так можно неплохо сэкономить память:)
Константин, спасибо за лекции! Можете, пожалуйста , разъяснить почему надо использовать aligned_storage а не просто написать union node {
node *next;
T storage;
};
Использование aligned_storage яснее выражает что мы хотим неинициализированное место для placement new. Использование просто T может вызвать иллюзию что мы и правда хотели бы хранить там T по значению.
А на вопрос про gcc и list на 56:00 есть ответ?
Ведет себя очень странно, когда вызывается list.remove gcc создает аллокатор инта из аллокатора ноды, потом создает аллокатор ноды из аллокатора инта, и видимо после ремува удаляет аллокатор с вынутой нодой.
51:29
У нас всегда условие this == &other будет true, мы в операторе сравнения это явно указали, и мы никогда ничего не мувнем. Может быть лучше листы сравнивать?
Так мы адреса сравниваем, а не объекты.)
@@epticemporio6734 да, действительно, моя ошибка
1:27:00 -- тут думаю холиварный вопрос про то, -- надо ли считать контейнеры с различными способами выделения памяти неэквивалентными (неравными)?
Он не столько холиварный сколько мы к нему ещё вернемся. Если аллокатор часть типа то ответ очень простой: да разные типы значит разные объекты. А вот если не часть типа, то.... (тут клиффхэнгер).
1:10:40 -- думаю gcc прав тут -- поскольку метод const arena_type& arena() выглядит как конструктор, однако с возвращаемым типом.
Почему же он конструктор если он в другом классе? Тут нужно точное обоснование где такое запрещено в стандарте.
почему statefull аллокаторы совсем не копируются при присваивании, почему нельзя сделать глубокую копию?
1:10:00 Константин, правильно ли я понимаю, что здесь срабатывает "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the
completed scope of S. No diagnostic is required for a violation of this rule" из С++20 и "The result of the search is the declaration set of S(M,T). If it is an invalid set, the program is ill-formed. If it differs from the result of a search in T for M in a complete-class context ([class.mem]) of T, the program is ill-formed, no diagnostic required." ([basic.lookup#class.member.lookup-6]) из С++23?
Если это так, за что же балл обещался?)
За это и обещался ))
Меня смущает, что для указателей используется static_cast, вместо reinterpret_cast.
Всегда когда возможно используйте static_cast.
Подскажите, пожалуйста, как вы называете конструктор с U, коэршен конструктор (типа когерентный, как на английском это пишется)?
Coersion
th-cam.com/video/5xN9bcdHggw/w-d-xo.html
- видимо, нет проверки на this == &rhs ?
Очевидно она там не нужна.
@@tilir наверное, я туплю, но я всегда считал, что в операторе присваивания и перемещения такая проверка нужна :(
В чём подвох?
@@alex_s_ciframi только если нужна особая обработка для a=a. Здесь проблем с таким присваиванием не будет. Ну и вообще хороший copy-assignment это обычно copy-and-swap где такая проверка тоже не нужна.
@@user-zu8oh8qg2v давайте дождёмся первого ответа в комментариях. А то будет не спортивно =)
28:00 но ведь если в 98 году в аллокаторе были запрещены иные typedef'ы, то как тогда они должны были возвращать far pointer'ы вектору? для них ведь отдельный тип заведён, а вы как раз раньше говорили, что их поддержка это единственная причина, по которой Степанов их изобрёл
23:40 а можете, пожалуйста, объяснить зачем это вообще было нужно добавлять? разве стандарт предусматривает какие-то другие способы вызвать конструктор? у меня есть догадка, что placement new не работал с far pointer'ами, но я не уверен насколько эта догадка верна