MM
Artöm Bakri Al-Sarmini
По значению его что-то другое не устроило
в том-то и фишка, что при передаче по значению тоже есть двойная индирекция
Size: a a a
2020 May 01
AB
Надо пересмотреть
v
в том-то и фишка, что при передаче по значению тоже есть двойная индирекция
Да что за индерецкия
MM
выглядит будто компилятор ниасилил доказать, что unique_ptr после перемещения 0
вот именно
CD
я про подобное очень много ныл, но нам нужно немного borrow checker, чтобы все работало
MM
В смысле условный delete? Он по стандарту обязан ничего не делать, если получил nullptr.
да, но в реализации проверка есть. хз, может так считается быстрее
v
да, но в реализации проверка есть. хз, может так считается быстрее
Значит авторы сделали лишнюю проверку снаружи delete, потому что она уже есть внутри.
CD
да, но в реализации проверка есть. хз, может так считается быстрее
в стандарте деструктор в точности кодом if (get_pointer()) get_deleter()(get_pointer())
v
в стандарте деструктор в точности кодом if (get_pointer()) get_deleter()(get_pointer())
Хочешь сказать кастомный удалятор уник птра не обязан быть валиден для nullptr?
CD
Хочешь сказать кастомный удалятор уник птра не обязан быть валиден для nullptr?
хочу сказать, что стандарт требует от unique_ptr не дергать с nullptr удалятор
v
хочу сказать, что стандарт требует от unique_ptr не дергать с nullptr удалятор
Вот откуда лишняя проверка.
CD
проблема-то не в этой проверке
CD
проблема, что тип переменной не может быть изменен после её создания :(
MM
Вот откуда лишняя проверка.
да можно было без проблем сделать другую реализацию для кастомного делитера
CD
и, видимо, С++ не хватает целого пласта runtime equivalent types
MM
проблема, что тип переменной не может быть изменен после её создания :(
эмм?..
AB
Может подумали, что ифчик лучше, чем лишний раз вызывать жирный кастомный удалятор
CD
эмм?..
представим код
void f(int x) {
if (x % 2) ++x;
//теперь x это четное число
}