Чистый С++: Как правильно разрушать

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

Как вы, наверное, заметили в прошлый раз, у класса есть очень важная вещь — деструктор! Эта функция будет вызвана ВСЕГДА, когда класс разрушается. Не важно что произошло, выход из функции посередине или даже выброшенное исключение, деструктор класса будет вызван в любом случае, пока программа работает. (Для справки, программа уже не работает, если исключение никто не ловит, поэтому в main нужно ставить try...catch на все типы исключений.). На C деструктор вызывается вручную, что заставляет писать много лишних подробностей.

if(!Create1(...))
    return -1;
if(!Create2(...))
{
    Destroy1(...);
    return -1;
}
…
if(!CreateN(...))
{
    Destroy1(...);
    Destroy2(...);
    ...
    DestroyN-1(...);
    return -1;
}

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

#include <iostream>
#include <stdexcept>

class Foo
{
private:
    static int sm_count;
    int instance;
public:
    Foo()
    {
        instance = ++sm_count;
        if(instance > 5)
            throw std::runtime_error("Нельзя создавать больше 5ти объектов.");
        std::cout << "Экземпляр № " << instance << " класса Foo создан.\n";

    }
    ~Foo()
    {
        std::cout << "Экземпляр № " << instance << " класса Foo разрушен.\n";
    }
};

int Foo::sm_count = 0;

int main()
{
    try
    {
        Foo* pFoo = new Foo[10];
    }
    catch(const std::exception& e)
    {
        std::cout << e.what() << "\n";
    }
    return 0;
}

Грамотное и повсеместное использование деструкторов приближает C++ по стилю программирования к языкам со сборщиком мусора. При таком подходе программист занят построением модели, а не выслеживанием симметричных выделений и освобождений ресурсов. Однако такое сближение сильно обманчиво и часто заканчивается обращением к удаленному с кучи объекту и аварийным выходом из программы. А если при этом еще активно пользоваться конструкциями языка C (упомянутый в прошлый раз «Ц с классами»), то однажды гарантированно произойдет обращение к данным объекта одного типа через указатель на другой тип. Вот очень хороший пример (делить на заголовочные файлы не обязательно, но полезно, чтобы было легко менять порядок их включения):

// HeaderFile1

class Interface1
{
public:
    virtual void SomeFunc(int a) = 0;
};

class Interface2
{
public:
    virtual void AnotherFunc(double b) = 0;
};

// HeaderFile2

class Implementation;

class Storage
{
private:
    Implementation* m_pImpl;
public:
    Storage(Implementation* in_pImpl)
        : m_pImpl(in_pImpl)
    {}

    Interface1* GetInterface1()
    {
        return (Interface1*)m_pImpl;
    }
    Interface2* GetInterface2()
    {
        return (Interface2*)m_pImpl;
    }
};

// HeaderFile3

#include <iostream>

class ImplementationBase
{
protected:
    virtual void BaseFunc()
    {
        std::cout << "BaseFunc была выполнена.\n";
    }
};

class Implementation
    : private ImplementationBase
    , public Interface1
    , public Interface2
{
public:
    virtual void SomeFunc(int a)
    {
        std::cout << "SomeFunc была выполнена с аргументом a = " << a << ".\n";
    }

    virtual void AnotherFunc(double b)
    {
        std::cout << "AnotherFunc была выполнена с аргументом b = " << b << ".\n";
    }
};

// C++ source file
// #include <HeaderFile1>
// #include <HeaderFile2>
// #include <HeaderFile3>

int main()
{
    Implementation impl;
    Storage storage(&impl);
    storage.GetInterface1()->SomeFunc(42);
    storage.GetInterface2()->AnotherFunc(37.7);
    return 0;
}

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

Вернемся к деструкторам. При их написании главное не бросить случайно исключение. Дело в том, что деструктор может быть вызван именно в процессе обработки исключения. В этом случае, процесс размотки стека процедуры размотки стека заканчивается самым простым и ожидаемым образом: немедленным выходом из программы. Так что внимательно за ними следите. Ни в коем случае не выделяйте в них память, ресурсы и уж тем более не бросайте исключений явно. Это требование диктует определенное отношение ко всяким «закрывающим» функциям. Например, какой нибудь Socket::Close() более не может сделать throw std::runtime_error("Close socket error: socket was not opened"). Дело в том, что самое логичное, что можно сделать с «закрывающей» функцией — вызвать ее в деструкторе. А вот обкладывать этот вызов различными проверками условий — совсем даже не логично. И если вы работаете в коллективе, то кто-то обязательно постарается закрыть уже закрытое. Так-что запишите себе куда нибудь простое правило: в любой «закрывающей» функции нужно тихо и без лишних телодвижений делать именно то, что от нее требуется — «закрыть» то, что просят, даже если это физически невозможно.
Еще раз обращаю внимание на то, что нельзя в таких функциях и деструкторах ничего выделять или захватывать. Очень распространенная ошибка:

~object::object()
{
    g_logger.put_message(std::string("Object ") + m_name + std::string(" was deleted."));
}

Если этот деструктор будет вызван в процессе обработки исключения вида «кончилась память», то вы долго будете искать причину вылета программы. При этом даже упомянутый тут логгер не поможет, т.к. не сумеет сформировать и сохранить так нужное сообщение. Как-же быть в такой ситуации? Самый простой способ, но не самый «красивый» — сгенерировать сообщение заранее, когда было все хорошо, и держать его в приватной части до поры до времени. Более «продвинутый» вариант:

~object::object()
{
    g_logger << "Object " << m_name << " was deleted.";
}

Надеюсь понятно, что g_logger здесь не имеет права заниматься выделениями памяти и открытиями файлов, а обязан иметь наготове буффер фиксированного размера и сливать его в заранее открытый файл по заполнению?

Плавно перейдем к выделению ресурсов. Правильный подход — сначала выделить, а затем использовать. Вот неправильный пример:

std::vector<int> items;
...
items.push_back(item1);
items.push_back(item2);
Правильно делать так:
std::vector<int> items;
...
items.reserve(items.size() + 2);
items.push_back(item1);
items.push_back(item2);

Нужно постоянно помнить о том, что память может кончится в самый неподходящий момент, и состояние программы в такой момент обязано оставаться определенным. Если обязано быть два элемента в массиве — значит либо два целых, либо ни одного. Никаких «недосозданных» структур данных быть не должно, т.к. это прямой путь к сбою при работе деструкторов. Хорошая программа — это такая, которая даже при нехватке памяти корректно сохраняет свои данные и тихо выходит. Ну, может быть не тихо, а вежливо попрощавшись. К сожалению, это не всегда так легко достижимо. Например, std::list не имеет метода reserve. Для таких случаев приходится заводить «пустое» состояние элемента данных, вроде null_ptr для указателей или -1 для индексов, и класть его сначала в структуру данных. А в деструкторе аккуратно обходить такие элементы. Здесь уместно вспомнить про увлечение всякими операторами, создающими на стеке временные объекты. Эти объекты, в свою очередь, выделяют ресурсы, которые не выделяются, а бросают исключение прямо посередине сложного выражения, оставляя части данного выражения в полувычесленном состоянии. Например итератор, сдвигаемый оператором ++ в середине выражения будет абсолютно бесполезен в секции catch.

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

typedef std::pair<int, int> DataItem;
std::vector<DataItem> items;
...
items.push_back(DataItem(item1, item2));

Однако это уже не такая простая тема моделирования предметной области поставленной задачи.