Сильное динамическое распределение Си ++ с уникальным_ptr?

Question

Я узнал, что unique_ptr может указывать на уже существующий объект. Например, я могу это сделать:

class Foo { 
public: 
    Foo(int nb) : nb_(nb) {} 
private: 
    int nb_; 
}; 

int main() { 
    Foo f1(2); 
    Foo* ptr1(&f1); 
    unique_ptr<Foo> s_ptr1(&f1); 

    return 0; 
} 

Мой вопрос:

Если я создаю класс с unique_ptr < Bar>, как члены данных (где Bar является класс, где был удален конструктор копирования) и конструктор, который принимает указатели в качестве аргумента, могу ли я запретить пользователю передавать уже существующий объект/переменную в качестве аргумента (в этом конструкторе) (то есть заставить его использовать новое ключевое слово)? Потому что, если он это сделает, я не смогу гарантировать состояние valide моих объектов класса (пользователь все еще может изменять элементы данных с их адресом извне класса) .. и я не могу скопировать содержимое Бар в другую область памяти. не

Пример:

class Bar { 
public: 
    Bar(/* arguments */) { /* data members allocation */ } 
    Bar(Bar const& b) = delete; 

    /* Other member functions */ 

private: 
    /* data members */ 
}; 

class Bar_Ptr { 
public: 
    Bar_Ptr(Bar* ptr) { 
    if (ptr != nullptr) { ptr_ = unique_ptr<Bar> (ptr); } 
    } /* The user can still pass the address of an already existing Bar ... */ 

    /* Other member functions */ 

private: 
    unique_ptr<Bar> ptr_; 
}; 

Answer 1

Вы не можете помешать программистам делать глупые вещи. Оба std::unique_ptr и std::shared_ptr содержат возможность создания экземпляра с существующим ptr. Я даже видел случаи, когда пользовательский удалён передается, чтобы предотвратить удаление. (Shared ptr более изящный для этих случаев)

Итак, если у вас есть указатель, вы должны знать его право собственности. Вот почему я предпочитаю использовать std::unique_ptr, std::shared_ptr и std::weak_ptr для указателей «владеющих», в то время как необработанные указатели представляют собой указатели, не являющиеся собственниками.Если вы распространяете это на место, где создается объект, большинство статических анализаторов могут сказать вам, что вы допустили ошибку.

Поэтому я хотел бы переписать класс Bar_ptr на что-то вроде:

class Bar_ptr { 
public: 
    explicit Bar_ptr(std::unique_ptr<Bar> &&bar) 
     : ptr(std::move(bar)) {} 
    // ... 
} 

С этого API вашего класса навязывает передачу права собственности, и это до вызывающей, чтобы обеспечить правильный unique_ptr. Другими словами, вы не должны беспокоиться о передаче указателя, который не выделен.

Никто не мешает абоненту из письма:

Bar bar{}; 
Bar_ptr barPtr{std::unique_ptr<Bar>{&bar}}; 

Хотя, если у вас есть приличный статический анализатор или даже просто обзор кода я ожидал бы этот код из отвергается.

Answer 2

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

Answer 3

Я видел нечто подобное раньше. Фокус в том, что вы создаете функцию (назовем ее make_unique), которая берет объект (не указатель, объект, поэтому, возможно, с неявным конструктором, он может «принимать» аргументы конструктора класса), и эта функция будет создавать и возвращать unique_ptr. Что-то вроде этого:

template <class T> std::unique_ptr<T> make_unique(T b); 

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

Answer 4

Вы не можете остановить людей от делать неправильные вещи , Но вы можете побудить их поступать правильно. Или, по крайней мере, если они делают не то, сделайте это более очевидным.

Например, с Bar, не позволяйте конструктору снимать голые указатели. Сделайте это unique_ptr s, либо по значению, либо по &&. Таким образом, вы вызываете вызывающего абонента для создания этих unique_ptr. Вы просто перемещаете их в свои переменные-члены.

Таким образом, если вызывающий абонент ошибается, ошибка указана в коде , а не на вашем.