Хранение ссылки против хранения копируемого объекта, реализованного с помощью PImpl?

Jamie S спросил: 13 октября 2017 в 07:33 в: c++

У меня есть класс с именем SharedData и объект Container с ~ 100k Individual объектами. Каждому из объектов Individual необходим доступ к данным, хранящимся в SharedData; поскольку их так много, хранить копии в каждом из них не представляется возможным. В настоящее время я храню ссылку на объект SharedData. Тем не менее, это, кажется, считается запахом кода; Кроме того, он предотвращает создание по умолчанию объектов Individual (для хранения в std::vector или QVector). В качестве возможного решения этой проблемы я рассмотрел вопрос о реструктуризации класса SharedData в соответствии с шаблоном проектирования pimpl:

class SharedData {
    QSharedPointer<PrivateSharedData> sharedDataPtr;
public:
    SharedData(...) : sharedDataPtr(new PrivateSharedData(...)) {}
    SharedData(const SharedData &other)
    {
        sharedDataPtr = other.sharedDataPtr;
    }    ...}

Это позволило бы каждому Individual для хранения копии объекта SharedData требует только sizeof(QSharedPointer) == 16 байтов памяти на Individual и допускает Individual s должен быть сконструирован по умолчанию и иметь свой элемент SharedData, инициализированный позже (например, через оператор присваивания).

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

0 ответов