Что не так с std::visit в современном C++

Собственно тут везде речь про один владеющий указатель в main, все остальные — разделяемые. Поэтому

1. Получается, нужно пользоваться сырыми указателями. Это очень неприятно и error-prone.
2. Нет, я не хочу передать владение. Есть мой ptr которым я владею, и я хочу дать им попользоваться. Ну например передал в поток, который каждую секунду выводит это сообщение в stdout. И после этого мутировать переданную переменную это ошибка. Можно от этого как-то защититься, не передавая владение?

Последнюю фразу не понял. Код, который получил указатель на константную память (не путать с константным указателем!) не может ее изменить. А чтобы получить обычный указатель из указателя на константную память, нужен const_cast. Другой кусок кода может получить указатель на тот же самый кусок памяти как на не-константный, тогда он сможет его менять.

Да, понял, что немного не так выразился. Тут просто еще вопрос скоупинга. Если посмотреть пример ниже, скоуп первого вызова явно ограничен { ... }, поэтому мы после этого можем мутировать переменную. Второй вызов имеет скоупом весь main и после этого мы мутировать переменную уже не можем. То есть нам нужно поведение как const, так и mut не в сигнатуре функции, а в сценарях её использования.

Так вы и не получите в C++ подобный контроль. Ни с умными указателями, ни без. Или вы сможете?

Разве повсеместное использование shared_ptr для ВСЕХ указателей не даст подобного контроля?

На всякий случай: в современном C++ голый указатель рассматривается как невладеющий. Т.е. дергать для него delete не рекомендуется. Предполагается, что время жизни контролирует тот, кто предоставил вам голый указатель.

благодарю, буду иметь в виду.

Ключевой момент в том, что нормальное применение unique_ptr/shared_ptr — это контроль жизни динамически созданного объекта.

Отвечаю как программист с опытом С++: на самом деле это не так. Это умные указатели. Они не контролируют время жизни, по Александреску они созданы для дереференса и для вызова правильного деструктора либо после разрушения переменной(unique_ptr), либо по достижению счетчика нуля(shared_ptr). Ну и в какой-то степени unique_ptr можно считать частным случаем shared_ptr.

Вопрос: почему они не контролируют время жизни объекта? Потому что RAII хорош только в том случае, когда ты используешь так называемые "правила хорошего тона". Вот как можно сломать unique_ptr:

#include <memory>

int main () {
  int* p = new int (10);
  std::unique_ptr<int> a (p);
  std::unique_ptr<int> b (p);
}

Программа будет завершена аварийно из-за попытки двойного освобождения. Если бы умные указатели контролировали время жизни объекта, такого бы не случалось.

Отвечаю как программист с опытом Rust: время жизни объектов контролирует сам язык, поэтому вышеуказанная ситуация в Rust в принципе не возможна. К примеру, Box используется для размещения объекта в куче (и вызове free при разрушении; почти как unique_ptr):

fn main() {
    let p = String::from("10");
    let a = Box::new(p);
    let b = Box::new(p);
}

Программа не соберется с ошибкой:

error[E0382]: use of moved value: `p`
 --> src/main.rs:4:22
  |
3 |     let a = Box::new(p);
  |                      - value moved here
4 |     let b = Box::new(p);
  |                      ^ value used here after move
  |

Вот что такое контроль времени жизни объекта. К Box/Rc/Arc это не имеет никакого отношения. Это вшито в язык, а не в библиотечный код.

И опять не понял. В Rust-е, afaik, типы Box/Rc/Arc так же являются частью стандартной библиотеки языка. И используются для тех же самых целей. Так почему же «и вы почувствуете, что unique_ptr и shared_ptr (которые сами по себе были глотком свежего воздуха), выглядят как неудачная шутка»?

Теперь можете сами попробовать почувствовать, шутка или нет.