Как лучше запретить копирование объекта?

Есть класс, надо запретить копирование его экземпляров. Можно как то сделать, чтоб в интерфейсе класса вообще не было конструктора копии и оператора копирующего присваивания?

0

Вот это как раз пустышки, а не потомки. Они не имеют смысла.

0

Сообщение от taras atavin Вот это как раз пустышки, а не потомки.

Просто для примера в них была опущена реализация, чтобы не загромождать.

0

Сообщение от 0x10 Просто для примера в них была опущена реализация,

в самом noncopyable.

0

Сообщение от taras atavin Вот это как раз пустышки, а не потомки. Они не имеют смысла.

Мне кажется ты конкретно что-то недопонимаешь.
Давай еще раз: noncopyable делает потенциального потомка некопируемым. Т.е. этот класс предназначен для того, чтобы от него отнаследовались и получили в наследнике запрет копирования. Ты же сам просил, чтобы в целевом классе не было конструктора копирования и оператора присваивания:

Можно как то сделать, чтоб в интерфейсе класса вообще не было конструктора копии и оператора копирующего присваивания?

Это и есть тот способ, который ты просил.
К слову, в boost используется точно такая же реализация noncopyable, как я привел.

Добавлено через 27 минут

Сообщение от taras atavin А кто Вам сказал, что у класса вообще есть наследники?

Мы сами это сказали, сделав его конструктор без параметров и деструктор protected. Нет иного выбора для использования, кроме как сделать наследование.
Вообще, чтобы ты знал, разрешение контракта на этапе компиляции очень полезная практика, к использованию которой всегда надо стремиться.

Сообщение от taras atavin По Вашему если экземпляр нельзя копировать, то класс - пустышка и ему нельзя иметь ни одного экземпляра, а запретить копирование надо не его экземпляров, а экземпляров потомков? Ну так замкнутый круг до бесконечности, порочным называемый: так как экземпляры потомков запрещено копировать, то по-Вашему они также не имеют смысла, это пустышки и запретить копирование надо уже для их потомков, но они тоже - пустышки по той же причине.

Нет, совсем не верно. По-нашему, - это есть зафиксированный утилитный класс и мы его применяем в качестве mix-in`а (ссылка) к тем нашим (твоим) классам, которые нужно сделать некопируемыми. Это такой прием. Причем древний. Он прекрасно гуглится.

Добавлено через 8 минут
taras atavin, В общем непонятно откуда вообще ты взял такие выводы про замкнутый круг и др.
Возьми да попробуй в конце концов. Увидишь, что никакого замкнутого круга нет Ответ тебе дали. Он верный. Подтвержден практикой и используется многими людьми по всему миру. Больше добавить нечего.

1

Сообщение от DrOffset В общем непонятно откуда вообще ты взял такие выводы про замкнутый круг и др. Возьми да попробуй в конце концов. Увидишь, что никакого замкнутого круга нет

Эйси. . Так как нельзя копировать экземпляры, то данный класс бессмыслен, а все экземпляры должны быть экземплярами CantCopy. Декларируем этот класс: . Но экземпляры этого класса тоже нельзя копировать, значит данный класс тоже бессмыслен, а все экземплярами CantCopy2. Декларируем этот класс: . И так до бесконечности.

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

Добавлено через 12 минут
Так что дефолтный конструктор как раз public. Кстати, абстрактые классы в обязательном порядке имеют не реализованные и перегружаемые в потомках виртуальные члены. Ну и где это здесь? Соответственно необходимость потомков не прослеживается. А дефолтный конструктор в protectd блокирует только создание экземпляров без использования параметров конструктора и, соответственно, создание динамических массивов безымянных экземпляров. Да и то за исключением локальных экземпляров в методах и операторах-членов как данного класса, так и потомков.
Ну и деструктор в protecte ограничивает область видимости экземпляров методами и операторами-членами данного класса и его потомков.

Добавлено через 1 минуту

Сообщение от DrOffset Ты же сам просил, чтобы в целевом классе не было конструктора копирования и оператора присваивания: Можно как то сделать, чтоб в интерфейсе класса вообще не было конструктора копии и оператора копирующего присваивания?

В самом классе, а не в его потомках.

Добавлено через 6 минут

Сообщение от DrOffset taras atavin, В общем непонятно откуда вообще ты взял такие выводы про замкнутый круг и др.

А откуда вообще вылезла абстрактность некопируемого класса? По бритве оккама не следует множить сущности на пустом месте, значит абстрактность класса из чего то выведена. Из чего? Единственный априорно известный признак - некопируемость, значит из неё. Но она распространяется на всех потомков, если из неё следует абстракность, значит они тоже должны быть абстрактны, причём, все. Абстрактный базовый класс ни кто не просил.

0

Сообщение от taras atavin И так до бесконечности.

А зачем это делать?

Сообщение от taras atavin А теперь как на самом деле. Из того, что экземпляр нельзя копировать не следует, что он не может существовать, наоборот, класс должен иметь собственные экземпляры, не имеют смысла только его потомки, поэтому их в проекте нет.

А где кто-то говорил, что экземпляр не может существовать?
Я говорил, что только сам noncopyable не имеет смысла создавать просто так, отдельно от всех. Это разные вещи. Класс, который ты от него наследуешь имеет смысл создавать, его-то конструкторы никто не помещает в private\protected.
Класс noncopyable создается один раз. Это как библиотечная сущность, вспомогательная. Никаких иерархий из них делать не предлагается и не предполагается. Он используется с целью навесить некопируемость на своего конкретного потомка. Это пример того, как в С++ иногда используется наследование вне контекста ООП. Ссылки хоть посмотри, там же все это объясняется.
Не спорь, разберись.

Добавлено через 42 секунды

Сообщение от taras atavin Но она распространяется на всех потомков, если из неё следует абстракность, значит они тоже должны быть абстрактны, причём, все.

Ничего подобного.

0

Сообщение от DrOffset А где кто-то говорил, что экземпляр не может существовать? Я говорил, что только сам noncopyable не имеет смысла создавать просто так, отдельбно от всех.

Я и говорю об экземпляре самого noncopyable.

0

Сообщение от taras atavin А откуда вообще вылезла абстрактность некопируемого класса?

Абстрактных классов тут нет вообще.

Добавлено через 39 секунд

Сообщение от taras atavin Я и говорю об экземпляре самого noncopyable.

Зачем ты о нем говоришь?

0

Сообщение от DrOffset Это как библиотечная сущность, вспомогательная. Никаких иерархий из них делать не предлагается и не предполагается. Он используется с целью навесить некопируемость на своего конкретного потомка.

А с какого он у Вас станет конкретным? Он же тоже не копируемый, из чего выведена абстрактность.

Добавлено через 2 минуты

Сообщение от DrOffset Абстрактных классов тут нет вообще.

Как это?

Сообщение от 0x10 делать его наследников некопируемыми. Создание объектов самого класса noncopyable смысла не имеет,

А это как раз определение абстрактного класса. В отличие от конкретных классов, которые могут иметь экземпляры, не являющиеся экземплярами их потомков. Разберитесь для начала в терминах.

0

Сообщение от taras atavin А с какого он у Вас станет конкретным? Он же тоже не копируемый, из чего выведена абстрактность.

У понятия абстрактный класс есть вполне конкретное определение в С++. Давай не будем придумывать термины.
Правильно этот класс называется mix-in. Я тебе давал выше ссылку. Вот определение оттуда:

При́месь (англ. mix in) — элемент языка программирования (обычно класс или модуль), реализующий какое-либо чётко выделенное поведение. Используется для уточнения поведения других классов, не предназначен для порождения самостоятельно используемых объектов.

Добавлено через 1 минуту

Сообщение от taras atavin Разберитесь для начала в терминах.

Вот сам и разберись.

На языке программирования C++ абстрактный класс объявляется включением хотя бы одной чистой виртуальной функции.

0

Сообщение от DrOffset У понятия абстрактный класс есть вполне конкретное определение в С++. Давай не будем придумывать термины.

Я и не придумываю. И не в языке c++, а вообще в объектно-ориентированном проектировании.

Абстрактным классом называется класс, который не может иметь экземпляров, не являющихся одновременно экземплярами его потомков.

.

0

Сообщение от taras atavin И не в языке c++, а вообще в объектно-ориентированном проектировании.

Мы находимся в разделе С++. И я настаиваю на том, что использовать нужно терминологию, которая принята в С++.

0

Это:

На языке программирования C++ абстрактный класс объявляется включением хотя бы одной чистой виртуальной функции, типа virtual _сигнатура_функции_ =0;, которая, как и другие, может быть заменена.

способ сделать класс абстрактным, а гарантированное отсутствие собственных экземпляров - определяющий признак. В других языках способом могло бы быть применение ключевого слова abstract совместно с ключевым словом class, или вместо него. , , , , или же может быть предусмотрен любой другой синтаксис. Но если семантика этого синтаксиса - запрет экземпляров непосредственно данного класса, то класс с таким синтаксисом абстрактен.

Добавлено через 2 минуты

Сообщение от DrOffset Мы находимся в разделе С++. И я настаиваю на том, что использовать нужно терминологию, которая принята в С++.

Понятие общее для ООП вообще. Если не согласны, предложите комитету назвать конкретно на языке c++ компилятором потоковый класс. Можно в связи с разделом избегать термина "метод" и заменять его словосочетанием "функция-член", на других языках обозначающее не самостоятельную сущность, а вид метода. Но c++ в них не входит и термины оттуда не наследует. А в ООП входит. Соответственно общие понятия имеют те же определения.

0

taras atavin, спор ни о чем.
В С++ у абстрактного класса конкретное определение.
Абстрактный класс предполагает, что он интерфейс, либо может им быть.

В нашем случае наследование - закрытое, следовательно это синтаксический вариант включения, а не каноническое ООП наследование - это раз.
И никакого интерфейса noncopyable не предоставляет - это два.
С++ никогда не реализовывал ООП в чистом виде с идеологической точки зрения. Оно всегда было чуть свое - это три.

Иными словами, раз уж мы в разделе по С++, то общаться нужно в терминах С++, дабы не путать себя и собеседников.

Добавлено через 1 минуту
taras atavin, мы ушли от темы. Что-то осталось непонятным?

0

Сообщение от DrOffset Абстрактный класс предполагает, что он интерфейс, либо может им быть.

Не выдумывай.

Добавлено через 1 минуту

Сообщение от DrOffset С++ никогда не реализовывал ООП в чистом виде с идеологической точки зрения. Оно всегда было чуть свое - это три.

Ни кто не реализовывал просто дверь в чистом виде, у всех она какая то своя.

0

Сообщение от taras atavin Не выдумывай.

Даже и не пытался. В С++ ты не можешь создать абстрактный класс, который бы одновременно не являлся интерфейсом. По определению.

Добавлено через 49 секунд

Сообщение от taras atavin Ни кто не реализовывал просто дверь в чистом виде, у всех она какая то своя.

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

0

Сообщение от DrOffset В нашем случае наследование - закрытое, следовательно это синтаксический вариант включения, а не каноническое ООП наследование - это раз.

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

0

taras atavin, По первоначальной теме есть что добавить?

0

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

Понятие абстрактного метода общее. Назови ручку на своей двери абырвалгом и ругайся со всеми гостями из-за применения ими общего слова.

0

Сообщение от taras atavin Понятие абстрактного метода общее. Назови ручку на своей двери абырвалгом и ругайся со всеми гостями из-за применения ими общего слова.

Все нормальные программисты С++ прекрасно понимают о чем идет речь, когда говорят про "абстрактный класс". Я бы поддержал тебя, будь мы в разделе ООП или еще каком общем теоретическом форуме.
Повторю вопрос.

Сообщение от DrOffset taras atavin, По первоначальной теме есть что добавить?

0