Является ли хорошей практикой, как правило, делать тяжеловесные классы несъемными?

Question

У меня есть класс Shape, содержащий потенциально много вершин, и я думал о том, чтобы сделать создание экземпляра copy-constructor/copy-assign частным, чтобы предотвратить случайное ненужное копирование моего тяжеловесного класса (например, передача по значению вместо ссылки).

Чтобы сделать копию Shape, нужно было бы сознательно называть метод «клонировать» или «дублировать».

Это хорошая практика? Интересно, почему контейнеры STL не используют этот подход, поскольку я редко хочу передавать их по значению.

Answer 1

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

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

Answer 2

В зависимости от ваших потребностей ...

Если вы хотите, чтобы убедиться, что копия не будет по ошибке, и сделать копию может вызвать серьезное узкое место, или просто не имеет смысла, то это хорошая практика. Ошибки компиляции лучше, чем исследования эффективности.

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

Answer 3

IMHO, предоставляющий конструктор копий и оператор присваивания или не зависит от того, что ваш класс моделирует, чем стоимость копирования.

Если ваш класс представляет значения, то есть, если передача объекта или копию объекта, не делают разницы, то предоставить им (и обеспечить оператор равенства также)

Если ваш класс ISN т. е. если вы думаете, что объект класса имеет идентификатор и состояние (также говорят о объектах), не надо. Если копия имеет смысл, предоставьте ей клон или экземпляр.

Иногда есть классы, которые вы не можете легко классифицировать. Контейнеры находятся в этом положении. Это означает, что рассматривать их как сущности и передавать их только по ссылке и выполнять специальные операции, чтобы сделать копию, когда это необходимо. Вы можете также рассматривать их просто как агрегирование значений, и поэтому копирование имеет смысл. STL был разработан вокруг типов значений. И поскольку все имеет значение, для контейнеров это имеет смысл. Это позволяет использовать такие вещи, как map<int, list<> >. (Помните, что в контейнере STL нельзя вводить nocopyable классы).

Answer 4

Как правило, вы не делаете классы не скопируемыми только потому, что они тяжелые (вы показали хороший пример STL).

Вы делаете их без копируемыми, когда они подключены к нек-Copyable ресурса как сокет, файл блокировки или они не предназначен для копирования на всех (например, есть некоторые внутренние структуры, которые вряд ли могут быть глубоко скопированные).

Однако, в вашем случае ваш объект можно копировать, поэтому оставьте его как это.

Небольшая заметка о clone() - используется как конструктор полиморфных копий - он имеет значение и используется по-разному.

Answer 5

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

Обратите внимание, что вектор, строка, карта, список и т. Д. Могут быть по-разному рассмотрены как «тяжеловесные» объекты (особенно что-то вроде вектора с 10 000 элементов!). Эти классы все еще предоставляют конструкторы копирования и операторы присваивания, поэтому, если вы знаете, что делаете (например, создаете std :: список векторов), вы можете их скопировать, когда это необходимо.

Так что если это полезно, укажите их в любом случае, но удостоверьтесь, что они дорогие операции.