Комментарии 4
Вот только std::optional<int&> невалиден, так что как минимум для этого указатели всё-ещё нужны
Увы, есть много библиотек, фреймворков и движков в которых инициализация объектов - это не одномоментное действие выполнимое в конструкторе. Поэтому если у этих объектов есть зависимости от других объектов реализовать поля для связи с зависимостями в ссылочных типах (которые обязаны инициализироваться на конструкторе) невозможно
Какой адовый треш. И этот человек себя позиционирует как C++ trainer.
#include <iostream>
#include <string>
using namespace std;
void foo(int* p) {
if (p == nullptr) return;
int& x = *p;
cout << x << "\n"; // output: 42
delete p; // this can happen externally, especially in a multi-threaded program
cout << x << "\n"; // output: UB
}
int main()
{
int* p = new int(42);
foo(p);
}
Я уже молчу о том, что этот самопровозглашенный коуч даже не затрагивает тему умных указателей, очевидно, потому что не знает, зачем их придумали (спойлер: именно из-за таких происшествий с ссылками).
Как бы, нет. Ваш пример некорректен.
Если у вас значения в других потоках меняются, то тут не в указателях дело, а нужно многопоточную синхронизацию предусматривать. Тут хоть контейнеры, хоть умные указатели делай - ничего не поможет без межпоточной синхронизации. Так что мимо.
Со второй придиркой аналогичные проблемы. Если вы получаете указатель а он где-то во внешнем коде освобождается пока функция не завершилась, то проблема не с указателями. Так у вас и значения в контейнерах могут измениться, и контейнеры освободиться. Указатели тут ни при чём
Долой указатели