Управление памятью вложенных классов

Содержание

Вопрос или проблема
Ответ или решение
Преимущества явного хранения указателей
Недостатки явного хранения указателей
Рекомендации
Заключение

Вопрос или проблема

Предположим, у меня есть несколько вложенных классов, называемых A, B и C. Объекты типа C содержат член типа B. Объекты типа B содержат член типа A.

Объект типа C создается в куче. Этот объект класса и его под-объекты объединены, так что все оказывается в куче.

В реализации для C и B есть ли какие-либо преимущества в явном удерживании указателей? Что-то вроде кода ниже?

С одной стороны, кажется неэффективным следовать при помощи цепочки указателей, чтобы получить доступ к данным. С другой стороны, возможно, это “безопаснее” для внутренних классов держать указатели, если не гарантируется, что внешние классы объявлены в куче? Есть ли что-то еще?

#include <iostream>
#include <memory> // std::unique_ptr

class A;
class B;
class C;

class A {
public:
    A() {
        std::cout << "Конструктор A" << std::endl;
    }
    ~A() {
        std::cout << "Деструктор A" << std::endl;
    }
};

class B {
public:
    std::unique_ptr<A> a_member; 

    B() : a_member(std::make_unique<A>()) { 
        std::cout << "Конструктор B" << std::endl;
    }
    ~B() {
        std::cout << "Деструктор B" << std::endl;
    }
};

class C {
public:
    std::unique_ptr<B> b_member; 

    C() : b_member(std::make_unique<B>()) { 
        std::cout << "Конструктор C" << std::endl;
    }
    ~C() {
        std::cout << "Деструктор C" << std::endl;
    }
};

int main() {
    auto c_ptr = std::make_unique<C>(); 
    return 0;
}

Есть ли какие-либо преимущества в явном удерживании указателей?

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

Идиома Pimpl, когда вы не раскрываете детали дочерних объектов, или используете стирание типов, когда детали дочернего объекта даже не известны. (std::any или std::function)
Полиморфизм, когда вы удерживаете указатель на некоторый базовый тип, и вместо этого передается указатель на производный тип (внедрение зависимостей)

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

Ответ или решение

Управление памятью для вложенных классов, таких как A, B и C, представляет собой важную тему, особенно в контексте производительности и безопасного обращения с ресурсами. Давайте рассмотрим ключевые моменты, связанные с использованием указателей и тем, есть ли преимущества в явном хранении указателей для вложенных классов.

Во-первых, важно понять, что объекты классов A, B и C могут быть размещены в памяти по-разному: на стеке или в куче. При создании объектов на куче, как вы это делаете в приведенном вами примере с использованием std::make_unique, вся иерархия объектов будет находиться в куче, что может быть полезно, если вы хотите управлять временем жизни объектов более гибко.

Преимущества явного хранения указателей

Управление временем жизни объектов: Использование std::unique_ptr или аналогичных указателей позволяет легче управлять временем жизни объектов. Когда указатель выходит из области видимости, он автоматически освобождает память, тем самым предотвращая утечки памяти. Это особенно важно, если у вас есть сложные структуры данных или вы работаете с большим количеством объектов.
Инкапсуляция: Явное использование указателей может быть полезно в контексте паттерна Pimpl (pointer to implementation), где вам нужно скрыть реализацию от пользователей класса. Это может повысить безопасность и удобство работы с классами.
Полиморфизм: Если ваши классы используются в контексте полиморфизма, где у вас есть базовый класс и несколько производных, использование указателей становится необходимым. Это позволяет вам хранить указатели на базовый класс и в случае необходимости заменять их на указатели на производные классы.

Недостатки явного хранения указателей

Производительность: Как вы правильно отметили, использование указателей может негативно сказаться на производительности из-за дополнительных разыменований. Каждый раз, когда нужно получить доступ к члену объекта через указатель, требуется разыменование. Это может добавить накладные расходы, особенно в популярных случаях, где это делается часто.
Сложность и риск ошибок: Указатели могут привести к более сложному коду и увеличить вероятность появления ошибок, таких как утечки памяти, двойное освобождение памяти, доступ к удаленной памяти и т.д. Система управления памятью становится более сложной, и разработчики должны быть особенно внимательны.

Заключение

Если в вашем проекте нет необходимости в использовании указателей (таких как в паттернах проектирования, требующих инкапсуляции, или при использовании полиморфизма), тогда лучше держать экземпляры классов A и B как обычные члены в классе C. Это обеспечит более высокую производительность и упростит управление памятью. Однако, если возникнет необходимость в более сложной структуре данных или функционала, использование указателей может оказаться полезным.