Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?
Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

auto_ptr нельзя применять в контейнерах. Используй boost::shared_ptr или напиши свой аналог.

Здравствуйте, Lexey, Вы писали:

А>>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

L>auto_ptr нельзя применять в контейнерах. Используй boost::shared_ptr или напиши свой аналог.

Ну вот я и хочу узнать почему нельзя... Примерчик с проблемкой можешь написать?

Здравствуйте, Аноним, Вы писали:

А>Ну вот я и хочу узнать почему нельзя... Примерчик с проблемкой можешь написать?

Да просто потому, что не предназначен он для этого. Разделяемый указатель должен считать ссылки. auto_ptr ссылки не считает.

Здравствуйте, Аноним, Вы писали:

А>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

Проблема — в том, что auto_ptr единолично владеет объектом, на который указывает.
Поэтому при копировании/присваивании получается, что несколько auto_ptr'ов указывают (и, следовательно, монопольно владеют) одним объектом.
Когда auto_ptr освобождается (в деструкторе или при изменении), он уничтожает объект. Все остальные указатели получают дохлую ссылку.

Здравствуйте, Аноним, Вы писали:

А>Ну вот я и хочу узнать почему нельзя...

например при сортировке вектора алгоритмом sort может быть такое — опорный элемент копируется во временную переменную, в нем остается NULL, а временная переменная уничтожается при выходе из области видимости. После сортировки имеем часть элементов вектора == NULL.

А>Примерчик с проблемкой можешь написать?

попробуй сам

Здравствуйте, Аноним, Вы писали:

А>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

#include <vector>
#include <memory>

int main()
{
  std::vector<std::auto_ptr<int> > v;
  v.push_back(std::auto_ptr<int>(new int(10)));
}

Данный пример не должен компилироваться соответствующим стандарту компилятором.

Здравствуйте, <Аноним>, Вы писали:

А>Ну вот я и хочу узнать почему нельзя... Примерчик с проблемкой можешь написать?

Согласно стандарту vector<auto_ptr<хоть что> > не должен даже компилироваться. А проблема в том, что STL полагается на то, что члены контейнеров реализуют присваивание без побочных эффектов.

Здравствуйте, Кодт, Вы писали:

К>Проблема — в том, что auto_ptr единолично владеет объектом, на который указывает.

А зачем там флажок bool _Owns ?

К>Поэтому при копировании/присваивании получается, что несколько auto_ptr'ов указывают (и, следовательно, монопольно владеют) одним объектом.

Они флажок переключают и объектом всегда только один владеет.

К>Когда auto_ptr освобождается (в деструкторе или при изменении), он уничтожает объект. Все остальные указатели получают дохлую ссылку.

Не получат (если auto_ptr'ы)

Здравствуйте, UgN, Вы писали:

К>>Проблема — в том, что auto_ptr единолично владеет объектом, на который указывает.

UgN>А зачем там флажок bool _Owns ?

Он используется при copy-конструировании auto_ptr, чтобы при передаче auto_ptr внуть функции он не порушил объект на выходе из нее.

К>>Поэтому при копировании/присваивании получается, что несколько auto_ptr'ов указывают (и, следовательно, монопольно владеют) одним объектом.

UgN>Они флажок переключают и объектом всегда только один владеет.

Это ничем не спасает в случае с stl-контейнерами, т.к. там после копирования разрушается не копия, а исходный указатель, который является оунером, и спокойно рушит объект.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>

ПК>#include <vector>
ПК>#include <memory>

ПК>int main()
ПК>{
ПК>  std::vector<std::auto_ptr<int> > v;
ПК>  v.push_back(std::auto_ptr<int>(new int(10)));
ПК>}
ПК>

ПК>Данный пример не должен компилироваться соответствующим стандарту компилятором.

А если будет обернут, то откомпилируется. (Если в вектор положить класс производный от auto_ptr)
Правильно ли я понимаю, что основная проблема, как указал m.a.g., в том, что

STL полагается на то, что члены контейнеров реализуют присваивание без побочных эффектов

?

Здравствуйте, Аноним, Вы писали:

ПК>>Данный пример не должен компилироваться соответствующим стандарту компилятором.

А>А если будет обернут, то откомпилируется. (Если в вектор положить класс производный от auto_ptr)

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

А>Правильно ли я понимаю, что основная проблема, как указал m.a.g., в том, что STL полагается на то, что члены контейнеров реализуют присваивание без побочных эффектов?

Формально, элементы стандартных контейнеров должны быть CopyConstructible и Assignable. std::auto_ptr не удовлетворяет этим требованиям.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Аноним, Вы писали:

А>>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

К>Проблема — в том, что auto_ptr единолично владеет объектом, на который указывает.
К>Поэтому при копировании/присваивании получается, что несколько auto_ptr'ов указывают (и, следовательно, монопольно владеют) одним объектом.
К>Когда auto_ptr освобождается (в деструкторе или при изменении), он уничтожает объект. Все остальные указатели получают дохлую ссылку.

Все это враки! Владеет только один, поэтому в конструкторе копирования для auto_ptr, параметер, переданный в конструктор, на самом деле модифицируется. Его указатель на "владеемый" элемент обнуляется.

Здравствуйте, UgN, Вы писали:

UgN>Здравствуйте, Кодт, Вы писали:

К>>Проблема — в том, что auto_ptr единолично владеет объектом, на который указывает.

UgN>А зачем там флажок bool _Owns ?

Нет там никакого флажка. Флажок ты увидел в реализации STL идущей с MSVC++ 6. Эта реализация 'auto_ptr' давно устарела и имеет мало общего с настоящей реализацией 'auto_ptr'. В правильной релизации 'auto_ptr' никакого флажка не нужно.

Здравствуйте, Аноним, Вы писали:

L>>auto_ptr нельзя применять в контейнерах. Используй boost::shared_ptr или напиши свой аналог.

А>Ну вот я и хочу узнать почему нельзя... Примерчик с проблемкой можешь написать?

Не нужен никако примерчик. Спецификация языка просто напросто открытым текстом запрещает исрользование 'std::auto_ptr' в контейнерах. На основании того, что 'std::auto_ptr' не удовлетворяет стандартным требованиям к элементу контейнера (CopyConstructible и Assignable). Да и не скомпилируется код просто напросто (см. пример в сообщении Павла Кузнецова).

С 'auto_ptr' из комплекта MSVC++ 6 это код скомпилируется. Но этот 'auto_ptr' к настоящему 'std::auto_ptr' почти никакого отношения не имеет.

Здравствуйте, Андрей Тарасевич, Вы писали:

UgN>>А зачем там флажок bool _Owns ?

АТ>Нет там никакого флажка. Флажок ты увидел в реализации STL идущей с MSVC++ 6. Эта реализация 'auto_ptr' давно устарела и имеет мало общего с настоящей реализацией 'auto_ptr'. В правильной релизации 'auto_ptr' никакого флажка не нужно.

Я был просто шокирован, когда не обнаружил у auto_ptr из STL от MSVC++ 6 метода reset().

АТ>>Нет там никакого флажка. Флажок ты увидел в реализации STL идущей с MSVC++ 6. Эта реализация 'auto_ptr' давно устарела и имеет мало общего с настоящей реализацией 'auto_ptr'. В правильной релизации 'auto_ptr' никакого флажка не нужно.

ME>Я был просто шокирован, когда не обнаружил у auto_ptr из STL от MSVC++ 6 метода reset().

появилась необходимость откомпилировать на 6ой студии со стандартной либо и тоже очумел
должно же бить какое то обновление?

Здравствуйте, Аноним, Вы писали:

А>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?
А>Спасибо.

std::vector<std::auto_ptr<int> > myVec;
// Здесь что-то вставляем в контейнер
std::sort(myVec.begin(), myVec.end(), some_pred);
// some_pred - некий предикат сравнения для std::auto_ptr<int>

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

Здравствуйте, Lexey, Вы писали:

L>Здравствуйте, Аноним, Вы писали:

А>>Не могли бы вы привести маленький примерчик, хорошо иллюстрирующий проблемы применения auto_ptr в STL контейнерах?

L>auto_ptr нельзя применять в контейнерах. Используй boost::shared_ptr или напиши свой аналог.

Никогда не варите яйцо в микроволновке :)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, dad, Вы писали:

АТ>>>Нет там никакого флажка. Флажок ты увидел в реализации STL идущей с MSVC++ 6. Эта реализация 'auto_ptr' давно устарела и имеет мало общего с настоящей реализацией 'auto_ptr'. В правильной релизации 'auto_ptr' никакого флажка не нужно.

ME>>Я был просто шокирован, когда не обнаружил у auto_ptr из STL от MSVC++ 6 метода reset().

dad>появилась необходимость откомпилировать на 6ой студии со стандартной либо и тоже очумел
dad>должно же бить какое то обновление?

Да — STLPort