Правило 6: Явно запрещайте компилятору генерировать функции, которые вам не нужны

Правило 6: Явно запрещайте компилятору генерировать функции, которые вам не нужны

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

class HomeForSale {...};

Любой агент по продаже недвижимости скажет вам, что каждый объект уникален – не бывает двух, в точности одинаковых. Вот почему идея создания копии объекта HomeForSale бессмысленна. Как можно скопировать нечто, по определению, уникальное? Поэтому хотелось бы, чтобы попытки скопировать объекты HomeForSale не компилировались:

HomeForSale h1;

HomeForSale h2;

HomeForSale h3(h1); // попытка скопировать h1 –

// не должно компилироваться!

h1 = h2; // попытка скопировать h2 –

// не должно компилироваться!

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

Похоже на безвыходное положение. Если вы сами не объявите конструктор копирования или оператор присваивания, то их сгенерирует компилятор. И ваш класс будет поддерживать копирование. Но то же самое произойдет, если вы объявите эти функции самостоятельно. Однако наша цель – предотвратить копирование!

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

Схема не идеальна, потому что другие члены класса и функции-друзья по-прежнему могут вызывать закрытые функции. Если только вы не включите лишь объявление, опустив определение. Тогда если кто-то случайно вызовет такую функцию, то получит сообщение об ошибке на этапе компоновки. Этот трюк – объявление функций-членов закрытыми и сознательный отказ от их реализации – как раз и используется для предотвращения копирования в некоторых классах библиотеки iostreams. Взгляните, например, на объявления классов ios_base, basic_ios и sentry в вашей реализации стандартной библиотеки. Вы обнаружите, что в каждом случае как конструктор копирования, так и оператор присваивания объявлены закрытыми и нигде не определены.

Применить эту уловку в классе HomeForSale несложно:

class HomeForSale {

public:

...

private:

HomeForSale(const HomeForSale&); // только объявления

HomeForSale& oparetor=( const HomeForSale&);

};

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

При таком определении компилятор будет блокировать любые попытки клиентов копировать объекты HomeForSale, а если вы случайно попытаетесь сделать это в функции-члене или функции-друге класса, то об ошибке сообщит компоновщик.

Существует возможность переместить ошибку с этапа компоновки на этап компиляции (это всегда полезно – лучше обнаружить ошибку как можно раньше), если объявить конструктор копирования и оператор присваивания закрытыми не в самом классе HomeForSale, а в его базовом классе, специально созданном для предотвращения копирования. Такой базовый класс очень прост:

class Uncopyable {

protected:

Uncopyable() {} // разрешить конструирование

~Uncopyable() {} // и уничтожение

// объектов производных классов

private:

Uncopyable(const Uncopyable&); // но предотвратить копирование

Uncopyable& operator=(const Uncopyable&);

};

Чтобы предотвратить копирование объектов HomeForSale, нужно лишь унаследовать его от Uncopyable:

class HomeForSale : private Uncopyable { // в этом класс больше нет ни

... // конструктора копирования, ни

} // оператора присваивания

Такое решение работает, потому что компилятор пытается генерировать конструктор копирования и оператор присваивания, если где-то – пусть даже в функции-члене или дружественной функции – производится попытка скопировать объект HomeForSale. Как объясняется в правиле 12, сгенерированные компилятором версии будут вызывать соответствующие функции из базового класса. Но это не получится, так как в базовом классе они объявлены закрытыми.

Реализация и использование класса Uncopyable сопряжена с некоторыми тонкостями. Например, наследование от Uncopyable не должно быть открытым (см. правила 32 и 39), а деструктор Uncopyable не должен быть виртуальным (см. правило 7). Поскольку Uncopyable не имеет данных-членов, то компилятор может прибегнуть к оптимизации пустых базовых классов, описанной в правиле 39, но коль скоро этот класс базовый, то возможно возникновение множественного наследования (см. правило 40). А множественное наследование в некоторых случаях не дает возможности провести оптимизацию пустых базовых классов (см. правило 39). Вообще говоря, вы можете игнорировать эти тонкости и просто использовать Uncopyable, как показано выше. Можете также воспользоваться версией из билиотеки Boost (см. правило 55). В ней этот класс называется noncopyable. Это хороший класс, но мне просто показалось, что его название немного, скажем так, неестественное.

Что следует помнить

• Чтобы отключить функциональность, автоматически предоставляемую компилятором, объявите соответствующую функцию-член закрытой и не включайте ее реализацию. Наследование базовому классу типа Uncopyable – один из способов сделать это.

Данный текст является ознакомительным фрагментом.



Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Функции, которые может вызывать ISR

Из книги автора

Функции, которые может вызывать ISR Следующий вопрос, за который следует взяться, — это список функций, которые может вызывать ISR.Небольшое отступление. Исторически, причина основных затруднений при написании обработчиков прерываний заключалась (и в большинстве других


44. Предпочитайте функции, которые не являются ни членами, ни друзьями

Из книги автора

44. Предпочитайте функции, которые не являются ни членами, ни друзьями РезюмеТам, где это возможно, предпочтительно делать функции не членами и не друзьями классов.ОбсуждениеФункции, не являющиеся членами или друзьями классов, повышают степень инкапсуляции путем


53. Явно разрешайте или запрещайте копирование

Из книги автора

53. Явно разрешайте или запрещайте копирование РезюмеКопируйте со знанием дела: тщательно выбирайте между использованием сгенерированных компилятором копирующего конструктора и оператора присваивания, написанием собственных версий или явным запрещением обоих, если


1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Из книги автора

1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix


1.6.12. Правило исправности: когда программа завершается аварийно, это должно происходить явно и по возможности быстро

Из книги автора

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


Правило 5: Какие функции C++ создает и вызывает молча

Из книги автора

Правило 5: Какие функции C++ создает и вызывает молча Когда пустой класс перестает быть пустым? Когда за него берется C++. Если вы не объявите конструктор копирования, оператор присваивания или деструктор самостоятельно, то компилятор сделает это за вас. Более того, если вы


Правило 9: Никогда не вызывайте виртуальные функции в конструкторе или деструкторе

Из книги автора

Правило 9: Никогда не вызывайте виртуальные функции в конструкторе или деструкторе Начну с повторения: вы не должны вызывать виртуальные функции во время работы конструкторов или деструкторов, потому что эти вызовы будут делать не то, что вы думаете, и результатами их


Правило 23: Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса

Из книги автора

Правило 23: Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса Возьмем класс для представления Web-браузера. В числе прочих такой класс может предлагать функции, который очищают кэш загруженных элементов, очищают историю посещенных URL и


Правило 25: Подумайте о поддержке функции swap, не возбуждающей исключений

Из книги автора

Правило 25: Подумайте о поддержке функции swap, не возбуждающей исключений swap – интересная функция. Изначально она появилась в библиотеке STL и с тех пор стала, во-первых, основой для написания программ, безопасных в смысле исключений (см. правило 29), а во-вторых, общим


Правило 36: Никогда не переопределяйте наследуемые невиртуальные функции

Из книги автора

Правило 36: Никогда не переопределяйте наследуемые невиртуальные функции Предположим, я сообщаю вам, что класс D открыто наследует классу B и что в классе B определена открытая функция-член mf. Ее параметры и тип возвращаемого значения не важны, поэтому давайте просто


Правило 37: Никогда не переопределяйте наследуемое значение аргумента функции по умолчанию

Из книги автора

Правило 37: Никогда не переопределяйте наследуемое значение аргумента функции по умолчанию Давайте с самого начала упростим обсуждение. Есть только два типа функций, которые можно наследовать: виртуальные и невиртуальные. Но переопределять наследуемые невиртуальные


1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Из книги автора

1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix


1.6.12. Правило исправности: когда программа завершается аварийно, это должно происходить явно и по возможности быстро

Из книги автора

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


4.5.3. Функции, которые создают новые конфигурации из существующих 4.5.3.1. Функции геометрии, которые производят новые конфигурации

Из книги автора

4.5.3. Функции, которые создают новые конфигурации из существующих 4.5.3.1. Функции геометрии, которые производят новые конфигурации Раздел "4.5.2. Функции Geometry" обсуждает несколько функций, которые создают новые конфигурации из


4.5.6. Функции, которые проверяют пространственные связи между конфигурациями

Из книги автора

4.5.6. Функции, которые проверяют пространственные связи между конфигурациями Спецификация OpenGIS определяет следующие функции. Они проверяют связь между двумя значениями геометрии g1 и g2.В настоящее время MySQL не выполняет эти функции согласно спецификации. Которые


БИБЛИОТЕЧНЫЕ ФУНКЦИИ, КОТОРЫЕ МЫ ИСПОЛЬЗОВАЛИ

Из книги автора

БИБЛИОТЕЧНЫЕ ФУНКЦИИ, КОТОРЫЕ МЫ ИСПОЛЬЗОВАЛИ      Пока мы хотим только перечислить эти функции, чтобы напомнить о них.      Сначала приведем функции ввода-вывода: getchar( )           /* получение символа */putchar( )           /* печать символа */gefs( )              /* получение