Д. Стефенс - C++. Сборник рецептов

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

Если вы пишете функцию или метод, создающий объекты, то посмотрите также рецепт 8.12. Используя шаблоны, функций можно написать одну функцию, которая будет возвращать новый объект любого типа. Например:

template

T* createObject() {

return(new T());

}

MyClass* p1 = createObject();

MyOtherClass* p2 = createObject();

// ...

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

Рецепт 8.12.

Для класса, представляющего некоторый ресурс, требуется использовать конструктор для получения этого ресурса и деструктор для его освобождения. Эта методика часто называется «получение ресурсов как инициализация» ( resource acquisition is initialization — RAII).

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

Пример 8.3. Использование конструкторов и деструкторов

#include

#include

using namespace std;

class Socket {

public:

Socket(const string& hostname) {}

};

class HttpRequest {

public:

HttpRequest(const string& hostname) :

sock_(new Socket(hostname)) {}

void send(string soapMsg) {sock << soapMsg;}

~HttpRequest() {delete sock_;}

private:

Socket* sock_;

};

void sendMyData(string soapMsg, string host) {

HttpRequest req(host);

req.send(soapMsg);

// Здесь делать ничего не требуется, так как когда req выходит

// за диапазон, все очищается.

}

int main() {

string s = "xml";

sendMyData(s, "www.oreilly.com");

}

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

Примерно так звучит обычный аргумент в пользу RAII. Я легко мог бы создать в примере 8.3 свой класс HttpRequest, который заставил бы пользователя выполнить несколько больше работы. Например:

class HttpRequest {

public:

HttpRequest();

void open(const std::string& hostname);

void send(std::string soapMsg);

void close();

~HttpRequest();

private:

Socket* sock_;

};

При таком подходе соответствующая версия sendMyDataможет выглядеть так.

void sendMyData(std::string soapMsg, std::string host) {

HttpRequest req;

try {

req.open();

req.send(soapMsg);

req.close();

} catch (std::exception& e) {

req.close(); // Do something useful...

}

}

Здесь требуется выполнить больше работы без каких бы то ни было преимуществ. Этот дизайн заставляет пользователя писать больше кода и работать с исключениями, очищая ваш класс (при условии, что в деструкторе closeне вызывается).

Подход RAII имеет широкое применение, особенно когда требуется гарантировать, что при выбрасывании исключения будет выполнен «откат» каких-либо действий, позволяя при этом не загромождать код бесконечными try/catch. Рассмотрим настольное приложение, которое в процессе выполнения какой-либо работы отображает в строке состояния или заголовка сообщение.

void MyWindow : thisTakesALongTime() {

StatusBarMessage("Copying files...");

// ...

}

Все, что класс StatusBarMessageдолжен сделать, — это использовать информацию о статусе для обновления соответствующего окна при создании и вернуть его первоначальное состояние при удалении. Вот ключевой момент: если функция завершает работу или выбрасывается исключение, StatusBarMessageвсе равно выполнит работу. Компилятор гарантирует, что при выходе из области видимости стековой переменной для нее будет вызван ее деструктор. Без этого подхода автор thisTakesALongTimeдолжен был бы принять во внимание все пути передачи управления, чтобы неверное сообщение не осталось в окне при неудачном завершении операции, ее отмене пользователем и т.п. И снова повторю, что этот подход приводит к уменьшению кода и снижению числа ошибок автора вызывающего кода.

RAII не является панацеей, но если вы его еще не использовали, то вы, скорее всего, найдете немало возможностей для его применения. Еще одним хорошим примером является блокировка. При использовании RAII для управления блокировками ресурсов, таких как потоки, объекты пулов, сетевые соединения и т.п., этот подход позволяет создавать более надежный код меньшего размера. На самом деле именно так многопоточная библиотека Boost реализует блокировки, делая программирование пользовательской части более простым. За обсуждением библиотеки Boost Threads обратитесь к главе 12.

Требуется хранить все экземпляры класса в едином контейнере, не требуя от пользователей класса выполнения каких-либо специальных операций.

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

Пример 8.4. Отслеживание объектов

#include

#include

#include

using namespace std;

class MyClass {

protected:

int value_;

public:

static list instances_;

MyClass(int val);

~MyClass();

static void showList();

};