Вероятно, я неправильно понял тот ваш пассаж, который цитировал. Думал, что речь про передачу указателя на себя во внешние функции, а не про неявный первый параметр.
В любом случае, я не понимаю, как связаны умные указатели и ваш пример. В нем как-раз нарушается правило единичного владения, про которое вы пишите в статье. Если узлы имеют ровно одного владельца, то почему владеющий указатель не заинкапсулирован внутри этого владельца, а лежит в глобальной переменной?
Согласен с соседними комментариями, что это очень неудачный пример кода.
Даже если мы передаем параметры в функции и храним локальные ссылки как shared_ptr<T>, мы все равно рискуем, потому что this все равно передается как T*
Разве не получится избежать этого через std::enable_shared_from_this?
Сам по себе мув же ничего не делает. Поведение будет зависеть от того, как именно его реализовать в классе - можно переприсвоить ресурсоы, а можно, как я понял, попробовать сделать релокацию. И тогда:
После этого можно использовать std::trivially_relocate(from_begin, from_end, to) функцию, чтобы переместить объект, завершить время жизни (lifetime) старых объектов и начать время жизни новых объектов. На практике, функция будет перемещать объекты через std::memmove, полностью избегая вызовов конструкторов и деструкторов.
А как соотносится Relocate с destructive move? Можно его в роли такового рассматривать? Или обращение к Relocate-нутому объекту будет старым добрым UB?
Вероятно, я неправильно понял тот ваш пассаж, который цитировал. Думал, что речь про передачу указателя на себя во внешние функции, а не про неявный первый параметр.
В любом случае, я не понимаю, как связаны умные указатели и ваш пример. В нем как-раз нарушается правило единичного владения, про которое вы пишите в статье. Если узлы имеют ровно одного владельца, то почему владеющий указатель не заинкапсулирован внутри этого владельца, а лежит в глобальной переменной?
Согласен с соседними комментариями, что это очень неудачный пример кода.
Разве не получится избежать этого через
std::enable_shared_from_this?Вы ведь сами спросили, что не так вашей статьей, а теперь обижаетесь.
Именно это в статье и раздражает.
Вы не Владимир Маяковский.
Да хотя бы даже форматирование.
Я на них плотно сижу, с тех пор как на 36 клавиш перешел. Есть косяки, нужно к таймингам нажатий привыкать, но когда привыкнешь - клевая штука.
Справедливости ради, в приведенной цитате от депутата именно про "блокировку" речь и не идет.
Сам по себе мув же ничего не делает. Поведение будет зависеть от того, как именно его реализовать в классе - можно переприсвоить ресурсоы, а можно, как я понял, попробовать сделать релокацию. И тогда:
Блок про
relocateкак раз об этом, по идее.А как соотносится Relocate с destructive move? Можно его в роли такового рассматривать? Или обращение к Relocate-нутому объекту будет старым добрым UB?
А что там по Safe C++, были разговоры? Или все, мертв?
Зато завезли std: :views: :split