Краткий ответ

Сырой указатель в такой функции следует рассматривать как невладеющий указатель: функция может использовать объект, но не должна удалять его, освобождать его ресурс или продлевать его время жизни. Вызывающий код обязан гарантировать, что объект существует всё время использования указателя.

После возврата из функции указатель нельзя сохранять для последующего доступа, если отдельно не гарантировано, что владелец переживёт это использование.

Исторический контекст

Сырые указатели появились как универсальный способ передавать адреса объектов и работать с памятью, массивами и системными ресурсами. Сам по себе тип указателя не кодирует, является ли указатель владельцем, наблюдателем или частью другого объекта.

RAII и умные указатели сделали владение ресурсами явным: std::unique_ptr выражает единственного владельца, а std::shared_ptr — совместное владение. Сырые указатели при этом остались полезны для невладеющего доступа, совместимости с низкоуровневыми интерфейсами и передачи уже существующих объектов без изменения их владельца.

Постановка проблемы

Если функция ошибочно считает сырой указатель владельцем, она может удалить объект, которым управляет std::unique_ptr, вызвать двойное освобождение или обратиться к объекту с неподходящим способом уничтожения. Если функция сохраняет указатель, а владелец уничтожает объект, возникает висячий указатель и неопределённое поведение при последующем доступе.

Обратная ошибка тоже опасна: если невладеющий интерфейс заменить на std::shared_ptr, функция может неожиданно продлить жизнь объекта. Это меняет семантику API и может привести к удержанию объектов дольше необходимого.

Подробное решение

Контракт функции должен явно означать: указатель используется только во время вызова, а управление временем жизни остаётся у вызывающего кода. Функция не должна выполнять delete, передавать указатель в механизм освобождения ресурса или сохранять его без отдельной гарантии времени жизни.

Минимальный пример:

#include <memory>

void print_value(const int* value) {
    if (value != nullptr) {
        // Только чтение во время вызова.
    }
}

int main() {
    auto owner = std::make_unique<int>(42);
    print_value(owner.get());
}

owner владеет объектом и уничтожает его при выходе из области видимости. Вызов get() передаёт только адрес; он не передаёт владение. Пока print_value выполняется и owner не уничтожен, доступ допустим.

Для изменяемого, но невладеющего доступа используют T*, а для обязательного присутствия объекта часто предпочитают T&. Ссылка не может быть нулевой, но также не продлевает время жизни и не является владельцем.

Если объект должен пережить текущий вызов, нужно изменить контракт: передать владение через std::unique_ptr, разделить владение через std::shared_ptr либо обеспечить внешнюю гарантию, например регистрацию и снятие регистрации до уничтожения владельца. Выбор shared_ptr оправдан только тогда, когда совместное владение действительно является частью модели, а не способом скрыть неясный жизненный цикл.

Ситуация из практики

Диспетчер событий хранит адрес обработчика, созданного компонентом приложения. Компонент может быть уничтожен раньше диспетчера, поэтому сохранённый сырой указатель станет недействительным.

Вариант с безусловным хранением shared_ptr прост и безопасен с точки зрения доступа, но диспетчер начнёт владеть обработчиком и может не дать ему уничтожиться вовремя. Вариант с сырым указателем не удерживает объект, однако требует строгого снятия регистрации перед уничтожением компонента; ошибка в этом протоколе приводит к неопределённому поведению.

Если обработчики уже управляются через shared_ptr, разумным решением может быть хранение weak_ptr: диспетчер не продлевает жизнь объекта, а перед вызовом временно получает shared_ptr и проверяет, что объект ещё существует. Если совместное владение не нужно, лучше оставить сырой указатель или ссылку и формализовать обязательное снятие регистрации.

Что кандидаты часто упускают

Достаточно ли передать const T*, чтобы гарантировать безопасность времени жизни?

Нет. const запрещает изменение объекта через данный указатель, но не делает указатель владельцем и не продлевает время жизни. Владелец всё ещё может уничтожить объект, после чего даже чтение через указатель будет неопределённым поведением.

Можно ли сохранить сырой указатель, полученный из std::unique_ptr, для последующего использования?

Только если есть внешняя гарантия, что соответствующий unique_ptr не уничтожит объект и не заменит управляемый объект до момента использования. Перемещение unique_ptr, само по себе, обычно не уничтожает объект, но уничтожение нового владельца, вызов reset() или перемещение другого объекта в тот же владеющий объект могут сделать сохранённый адрес недействительным.

Почему std::weak_ptr не является просто безопасным сырым указателем?

weak_ptr связан с контрольным блоком shared_ptr и может проверить, существует ли управляемый объект. Сырой указатель такой проверки не поддерживает: он содержит только адрес и не знает, уничтожен ли объект. Однако weak_ptr применим только в модели, где объект уже управляется shared_ptr; он не заменяет unique_ptr и не должен добавляться без необходимости совместного управления временем жизни.