Стенли Липпман - Язык программирования C++. Пятое издание

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

Sales_data::Sales_data(std::istream &is) {

read(is, *this); // read читает транзакцию из is в текущий объект

}

У конструкторов нет типа возвращаемого значения, поэтому определение начинается с имени функции. Подобно любой другой функции-члену, при определении конструктора за пределами тела класса необходимо указать класс, которому принадлежит конструктор. Таким образом, синтаксис Sales data::Sales_dataуказывает, что мы определяем член класса Sales_dataпо имени Sales_data. Этот член класса является конструктором, поскольку его имя совпадает с именем класса.

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

Члены, отсутствующие в списке инициализации конструктора, инициализируются соответствующим внутриклассовым инициализатором (если он есть) или значением по умолчанию. Для класса Sales_dataэто означает, что при запуске тела функции на выполнение переменная bookNoбудет содержать пустую строку, а переменные units_soldи revenue— значение 0.

Чтобы стало понятней, напомним, что второй параметр функции read()является ссылкой на объект класса Sales_data. В разделе 7.1.2 мы обращали внимание на то, что указатель thisиспользуется для доступа к объекту в целом, а не к его отдельному члену. В данном случае для передачи "этого" объекта в качестве аргумента функции read()используется синтаксис *this.

Упражнение 7.11. Добавьте в класс Sales_dataконструкторы и напишите программу, использующую каждый из них.

Упражнение 7.12. Переместите определение конструктора Sales_data(), получающего объект istream, в тело класса Sales_data.

Упражнение 7.13. Перепишите программу из раздела 7.1.1 так, чтобы использовать конструктор с параметром istream.

Упражнение 7.14. Напишите версию стандартного конструктора, явно инициализирующую переменные-члены значениями, предоставленными внутриклассовыми инициализаторами.

Упражнение 7.15. Добавьте соответствующие конструкторы в класс Person.

Кроме определения способа инициализации своих объектов, классы контролируют также то, что происходит при копировании, присвоении и удалении объектов класса. Объекты копируются во многих случаях: при инициализации переменной, при передаче или возвращении объекта по значению (см. раздел 6.2.1 и раздел 6.3.2). Объекты присваиваются при использовании оператора присвоения (см. раздел 4.4). Объекты удаляются, когда они прекращают существование, например, при выходе локального объекта из блока, в котором он был создан (см. раздел 6.1.1). Объекты, хранимые в векторе (или массиве), удаляются при удалении вектора (или массива).

Если мы не определим эти операции, компилятор создаст их сам. Обычно создаваемые компилятором версии выполняются, копируя, присваивая или удаляя каждую переменную-член объекта. Например, когда в приложении книжного магазина (см. раздел 7.1.1) компилятор выполняет следующее присвоение:

total = trans; // обработать следующую книгу

оно выполняется, как будто было написано так:

// присвоение по умолчанию для Sales_data эквивалентно следующему:

total.bookNo = trans.bookNo;

total.units_sold = trans.units_sold;

total.revenue = trans.revenue;

Более подробная информация об определении собственных версий этих операторов приведена в главе 13.

Некоторые классы не могут полагаться на синтезируемые версии

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