На днях столкнулся с одной интересной проблемой.
Понадобилось мне создать массив smart указателей. Не спрашивайте зачем.
Не долго думая, пишу следующий код —

[...]

class temp
{
};

typedef std::auto_ptr<temp> temp_ptr;
typedef typename std::deque<temp_ptr> temp_deque;

void main()
{
temp_ptr p(new temp);
temp_deque deq;
deq.push_back(p);
}

[...]

При компиляции ошибка, причем на строчку в недрах STL.
Начинаю разбираться. Не секрет, что при добавлении объекта, deque (как впрочем и остальные стандартные контейнеры) пользуются его копирующим коструктором. А конструктор, как изветно, принимает в качестве своего единственного параметра ссылку на константный копируемый объект. Но, (как я мог об этом забыть!) копирующий коструктор std::auto_ptr коренным образом отличается от своего _обычного_ собрата. Приставочки const у принимаемого объекта-то и нет. Не надо объяснять для чего это делалось разработчиками, и делалось конечно правильно, иначе как у копируемого объкта отобрать права владения указателем. Но вот мне — то как быть в этом случае?
По моему, даже если бы в std::auto_ptr кто-нибудь добрый добавил в конструкторе приставку const, а внутри применил преобразование типов — например const_cast, даже это не спасло бы отца русской демократии. Ведь ни кто не гарантирует что в STL не создадут (для каких нибудь профилактических целей) временный объект. И тогда права, отойдут в его безвременное, но к ложалению краткое пользование. С соответствующими последствиями.
Или, что вероятнее, пользователь такого deque (например я) может забыть с чем имеет дело и получить копию объекта из массива.
Вот и захотелось мне поинтересоваться у всезнающего ALL. Как быть бедному мне в этом случае и как работать с подобными классами в стандартных контейнерах (имеются ввиду классы копии которых владеют одним ресурсом).