Главное преимущество QString, на мой взгляд, это хорошая поддержка юникода прямо из коробки. Но зато занимает в два раза больше памяти, чем std::string.
ВУЗ - это не только знания, но еще и первый нетворкинг, возможность относительно безопасно покопаться в песочнице (в т.ч. с такими вот проектами, как у вас), ну и в любом случае база, которая не будет совсем уж лишней.
Мое мнение, как ноунейма из сети - полностью откидывать идею ВУЗа не стоит, если вопрос чисто в отсутствии интереса. Если в качестве альтернативы у вас нет возможности работать в реальной команде над реальными проектами, то это будет ошибкой, т.к. проекты из поста ни к чему вас не приведут (разве что помогут вам выучить какие-то навыки сомнительной полезности).
Вероятно, я неправильно понял тот ваш пассаж, который цитировал. Думал, что речь про передачу указателя на себя во внешние функции, а не про неявный первый параметр.
В любом случае, я не понимаю, как связаны умные указатели и ваш пример. В нем как-раз нарушается правило единичного владения, про которое вы пишите в статье. Если узлы имеют ровно одного владельца, то почему владеющий указатель не заинкапсулирован внутри этого владельца, а лежит в глобальной переменной?
Согласен с соседними комментариями, что это очень неудачный пример кода.
Даже если мы передаем параметры в функции и храним локальные ссылки как 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?
Главное преимущество QString, на мой взгляд, это хорошая поддержка юникода прямо из коробки. Но зато занимает в два раза больше памяти, чем std::string.
ВУЗ - это не только знания, но еще и первый нетворкинг, возможность относительно безопасно покопаться в песочнице (в т.ч. с такими вот проектами, как у вас), ну и в любом случае база, которая не будет совсем уж лишней.
Мое мнение, как ноунейма из сети - полностью откидывать идею ВУЗа не стоит, если вопрос чисто в отсутствии интереса. Если в качестве альтернативы у вас нет возможности работать в реальной команде над реальными проектами, то это будет ошибкой, т.к. проекты из поста ни к чему вас не приведут (разве что помогут вам выучить какие-то навыки сомнительной полезности).
А вас тоже можно убедить в чем угодно меньше, чем за 5 минут? Или вы не рядовой обыватель?
Он и не должен от него защищать.
Я же написал, что упомянул
shared_from_thisв контексте передачиthisв параметры функции. В вашем примере такой передачи нет.Вероятно, я неправильно понял тот ваш пассаж, который цитировал. Думал, что речь про передачу указателя на себя во внешние функции, а не про неявный первый параметр.
В любом случае, я не понимаю, как связаны умные указатели и ваш пример. В нем как-раз нарушается правило единичного владения, про которое вы пишите в статье. Если узлы имеют ровно одного владельца, то почему владеющий указатель не заинкапсулирован внутри этого владельца, а лежит в глобальной переменной?
Согласен с соседними комментариями, что это очень неудачный пример кода.
Разве не получится избежать этого через
std::enable_shared_from_this?Вы ведь сами спросили, что не так вашей статьей, а теперь обижаетесь.
Именно это в статье и раздражает.
Вы не Владимир Маяковский.
Да хотя бы даже форматирование.
Я на них плотно сижу, с тех пор как на 36 клавиш перешел. Есть косяки, нужно к таймингам нажатий привыкать, но когда привыкнешь - клевая штука.
Справедливости ради, в приведенной цитате от депутата именно про "блокировку" речь и не идет.
Сам по себе мув же ничего не делает. Поведение будет зависеть от того, как именно его реализовать в классе - можно переприсвоить ресурсоы, а можно, как я понял, попробовать сделать релокацию. И тогда:
Блок про
relocateкак раз об этом, по идее.А как соотносится Relocate с destructive move? Можно его в роли такового рассматривать? Или обращение к Relocate-нутому объекту будет старым добрым UB?
А что там по Safe C++, были разговоры? Или все, мертв?
Зато завезли std: :views: :split