У меня есть std::unique_ptr и еще один необработанный указатель. Я хочу, чтобы необработанный указатель указывал на содержимое unique_ptr без какого-либо права собственности. Это отношение только для чтения:Указывает на содержание std :: unique_ptr
auto bar=std::make_unique<foo>();
auto ptr=bar.get();// This may point to another value later
Это плохо? Есть ли альтернатива?
Примечание: настоящий пример более сложный. Они не в одном классе.
Если вы можете гарантировать, что A)bar «s срок службы превышает срок службы ptr И B), что ни один программист/рефакторинга никогда не будет писать delete ptr; в любой момент, то это совершенно нормально, и, вероятно, идеально подходит для любой ситуации, когда вам необходимо передать указатели без права собственности.
Если эти два условия не могут быть гарантированы, вероятно, вы должны использовать std::shared_ptr и std::weak_ptr.
И вы, вероятно, не должны использовать 'shared_ptr', потому что 99%« подождите, я могу решить свои проблемы с ресурсами с 'shared_ptr'», в конечном итоге, является плохой идеей. – Yakk
@Yakk В лучшем случае я бы назвал это гиперболическим, а в худшем - наивным. Я столкнулся с множеством проблем на земле C++, где лучшее, самое идиоматическое решение вызвало использование 'std :: shared_ptr'. Я дам вам, что зависимость от указателей в первую очередь имеет тенденцию представлять причину (или симптом) сложности проектирования, но если они были плохими «99% времени», Java (которая в основном использует объекты, подобные shared_ptr) для всех его указателей) будет непригодным для использования в качестве языка, и мы знаем, что это не так. – Xirema
Мы действительно это знаем? Но серьезно, Java использует полные указатели gc, которые представляют собой другой зверь, чем указатели rc. Размышление о указателях rc как о каком-то реальном указателе gc является признаком фундаментальной ошибки в дизайне компонента, и такие ошибки являются частью этого 99%. Я нашел ситуации, когда общие указатели правильны (когда у вас есть фактическое * совместное владение * какого-то ресурса, а не просто «я не хочу думать о проблемах с помехами здесь»), но редко может возникать общая проблема, связанная с существованием пожизненного быть решен путем простого перетаскивания общих и слабых указателей в систему. – Yakk
Нет, это не плохо, и до тех пор пока стандартная библиотека не включает proposed std::observer_ptr, это идиоматического способ выражения, не владеющий наблюдателя.
И даже после этого это будет идиоматический способ представления этого. В директивах Core C++ не говорится об использовании 'observer_ptr'; они говорят, что все голые 'T *' s представляют собой несоблюдение. –
@NicolBolas Это вопрос, будут ли они говорить, что после 'std :: experimental :: observer_ptr' станет' std :: observer_ptr'. Я могу представить, что руководство превратилось в «прочитанное' T * 'как несоблюдение, но напишите без права собственности как' std :: observer_ptr
"* Это вопрос, будут ли они все еще говорить, что после того, как' std :: experimental :: observer_ptr' станет 'std :: observer_ptr'. *« И это вопрос, действительно ли это произойдет; Изменение ТС между предлагаемыми и принятыми в основной стандарт. Кроме того, это не волшебным образом преобразует * миллиарды * строк существующего кода на C++, которые используют голой указатель для неопубликованных указателей. –
Не должно быть 'bar.get();'? –
@ πάνταῥεῖ да извините –
Я бы сказал, что это идеально. Но я бы выбрал другое имя, так как уже существует 'std :: weak_ptr' с другой семантикой. – Galik