Должен ли я использовать shared_ptr или unique_ptr

Я делал некоторые объекты, используя идиому pimpl, но я не уверен, использовать ли shared_ptr или unique_ptr.

Определенно unique_ptr или scoped_ptr.

Pimpl — это не шаблон, а идиома, имеющая дело с зависимостью во время компиляции и бинарной совместимостью. Это не должно влиять на семантику объектов, особенно в отношении их поведения при копировании.

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

Однако эти объекты в действительности не копируются, так как изменения затрагивают все копии, поэтому мне было интересно, что, возможно, использование shared_ptr и разрешение копий является своего рода анти-шаблоном или плохой вещью.

Это не анти-шаблон, на самом деле это шаблон: Псевдоним. Вы уже используете его в C++ с голыми указателями и ссылками. shared_ptr предлагают дополнительную меру «безопасности», чтобы избежать мертвых ссылок за счет дополнительной сложности и новых проблем (остерегайтесь циклов, которые создают утечки памяти).

Не имеет отношения к прыщам

Я понимаю, что unique_ptr более эффективен, но для меня это не такая большая проблема, так как эти объекты в любом случае относительно тяжелые, поэтому стоимость shared_ptr по сравнению с unique_ptr относительно невелика.

Если вы можете выделить некоторое состояние, вы можете взглянуть на шаблон Flyweight.

Если вы используете shared_ptr, это не совсем классическая идиома pimpl (если вы не предпримете дополнительные шаги). Но настоящий вопрос заключается в том, почему вы хотите использовать интеллектуальный указатель для начала; совершенно ясно, где должно произойти delete, и нет проблем с безопасностью исключений или чем-то другим, о чем нужно беспокоиться. В лучшем случае умный указатель сэкономит вам одну-две строки кода. И единственная, которая имеет правильную семантику, это boost::scoped_ptr, и я не думаю, что она работает в данном случае. (IIRC, для создания экземпляра требуется полный тип, но я могу ошибаться.)

Важным аспектом идиомы pimpl является то, что ее использование должно быть прозрачным для клиента; класс должен вести себя точно так же, как если бы он был реализован классически. Это означает либо запрещение копирования и присваивания, либо реализацию глубокого копирования, если только класс не является неизменяемым (нет неконстантных функций-членов). Ни один из обычных интеллектуальных указателей не реализует глубокое копирование; вы, конечно, можете реализовать его, но, вероятно, все равно потребуется полный тип всякий раз, когда происходит копирование, а это означает, что вам все равно придется предоставить определяемый пользователем конструктор копирования и оператор присваивания (поскольку они не могут быть встроенными). Учитывая это, вероятно, не стоит заморачиваться с использованием интеллектуального указателя.

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

Когда вы используете shared_ptr (например, в контейнере, затем ищете это и возвращаете по значению), вы не вызываете копию объекта, на который он указывает, просто копию указателя со счетчиком ссылок.

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

При передаче shared_ptr (как говорится в комментариях) лучше передать константную ссылку и скопировать (там, увеличив счетчик ссылок) там, где это необходимо. Что касается возврата, в каждом конкретном случае.

Да, пожалуйста, используйте их. Проще говоря, shared_ptr — это реализация интеллектуального указателя. unique_ptr — это реализация автоматического указателя: