Можно ли хранить объекты класса с std :: auto_ptr в качестве его переменной-члена в std :: vector?

Question

Я не могу использовать shared_ptr в моем проекте, не подталкивание :(

Итак, у меня есть класс, примерно аналогичный приведенному ниже:

class MyClass 
{ 
private: 
    std::auto_ptr<MyOtherClass> obj; 
}; 

Теперь я хочу, чтобы хранить экземпляры из выше класса в станд :: вектор. безопасно? Я read here, что это неправильно использовать зЬй :: auto_ptr с STL контейнеров. Относится ли это к моей ситуации здесь?

Answer 1

Я отправил вопрос в качестве последующего ответа на этот ответ, см. Class containing auto_ptr stored in vector.

Ассистент вашего класса не имеет определяемого пользователем конструктора копирования, а затем нет, вероятно, (см. Ниже) небезопасно. Когда ваш класс будет скопирован (как это произойдет, когда он будет добавлен в вектор), будет использован конструктор копирования auto_ptr. У этого есть странное поведение transanferring собственности на вещь, скопированную в копию, и, таким образом, указатель на копирование теперь является нулевым.

Возможно, вы вряд ли захотите этого поведения, и в этом случае auto_ptr будет безопасным. Предполагая, что вы этого не сделаете, вы должны либо:

• добавить конструктор копирования для управления копировального

Примечания этого не достаточно - увидеть последующий вопрос упомянутого выше для получения дополнительной информации.

или:

• использование умнее, возможно, подсчет ссылок указатель, например, один из наддува смарт-указатели

Answer 2

Копирование объекта MyClass вызовет либо позвонить оператору присваивания или конструктор копирования. Если они не перегружены для обработки auto_ptr <> необычным способом, они будут распространять вызов для копирования конструктора (или оператора присваивания) члену auto_ptr <>. Это может привести к проблемам, описанным в вопросе, который вы связали.

Answer 3

Это не безопасно, если контейнер будет скопирован. Оператор копирования MyClass instnace по умолчанию будет вызывать копирование для всех участников - и для члена auto_ptr тоже, и мы будем иметь такую ​​же ситуацию, какую вы описали в своем вопросе (сохранение auto_ptr в контейнере)

BTW: для избежания путаницы во время компиляции добавить

private: 
    MyClass& operator=(const MyClass&); 
    MyClass(const MyClass&); 

вывода ошибки компилятора, если вы постараетесь операторы использования копирования, это может спасти вас от часов отладки.

Answer 4

Это не сработает. auto_ptr не учитывает ссылки, что означает, что при первом вызове деструктора ваш указатель будет освобожден.

Используйте boost :: shared_ptr вместо этого.

Answer 5

Причина, по которой нецелесообразно инициировать вектор auto_pointer, заключается в том, что существует алгоритм: sort(), который будет делать копию одного объекта в вашем контейнере в стеке. (sort() реализует quicksort, который нуждается в «своде») И, следовательно, удаление его при выходе из scpope функции sort(). Как и любой алгоритм или ваша собственная функция, способная взять ваш контейнер в качестве параметра и скопировать один из его объектов в стек, приведет к этой проблеме в результате.

Ну, в вашем случае, вы должны убедиться, что ваш класс не ведет себя как auto_ptr, или убедитесь, что вы никогда не вызовете такую ​​функцию/алгоритм, который может удалить ваши базовые объекты. Первое решение лучше всего, согласно мне :)

Итак, ваш конструктор копий и ваш оператор аффектации также не должны отбрасывать свойство объекта-указателя.

Лучший способ добиться этого - обернуть интеллектуальный указатель boost вместо auto_ptr, чтобы сделать ваш контейнер безопасным при вызове такой функции/алгоритма.

44. Я считаю, результат применения алгоритма sort().

Answer 6

Как сказал Нил Баттерворт, auto_ptr, вероятно, не путь.

boost::shared_ptr ясно, но вы говорите, что вы не можете использовать boost.

Позвольте мне упомянуть, что вы можете загрузить boost, извлечь, что вам нужно для общего \ ptr, только используя bcp tool и использовать boost::shared_ptr. Это означало бы только несколько добавленных файлов hpp в вашем проекте. Я считаю, что это правильный путь.

Answer 7

Это не действительный, чтобы иметь объект, который содержит auto_ptr в стандартном контейнере. Вы сталкиваетесь с неопределенным поведением. Две распространенные проблемы:

• std :: vector <> :: resize копирует свой аргумент в каждый созданный элемент. Первая копия будет «успешной» (см. Ниже почему нет), но каждая последующая копия будет пустой, потому что скопированный элемент также пуст!
• Если что-то во время перераспределения бросает, у вас могут быть некоторые элементы, скопированные (в новый буфер), - но отбрасываемая копия - и другие элементы нет, потому что push_back не должен иметь никаких эффектов, если генерируется исключение. Таким образом, некоторые из ваших элементов теперь пусты.

Как это все о неопределенном поведении, это не имеет большого значения. Но даже , если мы пытаемся придумать такое поведение, основанное на том, что мы считаем действительным, мы все равно потерпим неудачу. Все функции-члены, такие как push_back, resize и т. Д., Имеют ссылку на const, которая принимает объект типа T. Таким образом, ссылка типа T const& пытается скопировать в элементы вектора. Но неявно созданный оператор компоновщика копий/копий выглядит как T(T&), то есть для его копирования требуется объект non-const. Хорошие реализации стандартной библиотеки проверяют это, и при необходимости не скомпилируются.

До следующей версии на C++ вы должны жить с этим.Следующий будет поддерживать типы элементов, которые являются просто подвижным. То есть перемещенный объект не должен быть равен перемещенному объекту. Это позволит помещать потоки, указатели на перевод и ниток в контейнеры.

Посмотрите, что говорит стандарт для этого (17.4.3.6):

В некоторых случаях (замена функций, функций обработки, операций по типам используемых для создания экземпляров стандартных компонентов библиотеки шаблонов), С ++ Стандартная библиотека зависит от компонентов поставляемый программой C++. Если эти компоненты не соответствуют их требованиям, Стандарт не устанавливает никаких требований к реализации.

В частности, эффекты не определены в следующих случаях:

• для типов, используемых в качестве аргументов шаблона при создании экземпляра шаблона компонента, если операции по типу не реализуют семантику применимых требований подпункта (20.1.5, 23.1, 24.1, 26.1).

Answer 8

Если вы хотите использовать класс, который использует auto_ptr в контейнере, вы можете просто предоставить копию-конструктор и оператор присваивания себе:

class MyClass 
{ 
private: 
    const std::auto_ptr<MyOtherClass> obj; // Note const here to keep the pointer from being modified. 

public: 
    MyClass(const MyClass &other) : obj(new MyOtherClass(*other.obj)) {} 
    MyClass &operator=(const MyClass &other) 
    { 
     *obj = *other.obj; 
     return *this; 
    } 
}; 

Но, как уже отмечалось, стандарт позволяет контейнеры делают копии и присваивания и предполагает, что содержащиеся классы будут вести себя определенным образом, что нарушает auto_ptr. Определив вышеописанные методы, вы можете создать класс, содержащий поведение auto_ptr. Даже если ваша реализация отлично работает с auto_ptrs, вы рискуете найти другую реализацию, которая не работает. Стандарт гарантирует только производительность и наблюдаемое поведение, а не реализацию.