<auto_ptr> inside <map> problem in VC 7!??

  • Thread starter Thread starter Evgeny
  • Start date Start date
E

Evgeny

Hi, all!

I didn't find yet solution for this problem! Somebody knows where is a
catch?
Looks like "operator =" or copy constructor not implemented in one of
internal templates....

Thanks in advance

class CMyBase;
typedef auto_ptr<CMyBase> MyBasePtr;
typedef map<int, MyBasePtr> MAP_BASE;

class CMyBase
{
public:
CMyBase()
{ }
virtual ~CMyBase()
{ }
virtual MyBasePtr Clone(void) const
{ return MyBasePtr(new CMyBase()); }
virtual MyBasePtr Test()
{
MAP_BASE _map2;
_map2[1] = m_map.begin()->second->Clone();// Compiler error occured:
C2558: class 'std::auto_ptr<_Ty>' : no

//copy constructor available or copy constructor is declared 'explicit'
}
private:
MAP_BASE m_map;
};
 
std::auto_ptr can not be used with most containers. One alternative is
boost::shared_ptr.

Dan
 
Evgeny said:
class CMyBase;
typedef auto_ptr<CMyBase> MyBasePtr;
typedef map<int, MyBasePtr> MAP_BASE;
Click to expand...

you MAY NOT use std::auto_ptr inside STL containers! It's violation of
language rules and MSVC is right generating compilation error. That's
because *for auto_ptr, copies are NOT equivalent*. Here what Herb Sutter
says about it at
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm :
It is never safe to put auto_ptrs into standard containers. Some people
will tell you that their compiler and library compiles this fine, and
others will tell you that they've seen exactly this example recommended
in the documentation of a certain popular compiler; don't listen to
them.
The problem is that auto_ptr does not quite meet the requirements of a
type you can put into containers, because copies of auto_ptrs are not
equivalent. For one thing, there's nothing that says a vector can't just
decide to up and make an "extra" internal copy of some object it
contains. For another, when you call generic functions that will copy
elements, like sort() does, the functions have to be able to assume that
copies are going to be equivalent. At least one popular sort internally
takes a copy of a "pivot" element, and if you try to make it work on
auto_ptrs it will merrily take a copy of the pivot auto_ptr object
(thereby taking ownership and putting it in a temporary auto_ptr on the
side), do the rest of its work on the sequence (including taking further
copies of the now-non-owning auto_ptr that was picked as a pivot value),
and when the sort is over the pivot is destroyed and you have a problem:
At least one auto_ptr in the sequence (the one that was the pivot value)
no longer owns the pointer it once held, and in fact the pointer it held
has already been deleted!
If you want to use smart pointers inside containers, use
boost::shared_ptr from http://www.boost.org/libs/smart_ptr/index.htm


Kind regards


B.
 
Thanks a lot!

Bronek Kozicki said:
you MAY NOT use std::auto_ptr inside STL containers! It's violation of
language rules and MSVC is right generating compilation error. That's
because *for auto_ptr, copies are NOT equivalent*. Here what Herb Sutter
says about it at
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm :

It is never safe to put auto_ptrs into standard containers. Some people
will tell you that their compiler and library compiles this fine, and
others will tell you that they've seen exactly this example recommended
in the documentation of a certain popular compiler; don't listen to
them.
The problem is that auto_ptr does not quite meet the requirements of a
type you can put into containers, because copies of auto_ptrs are not
equivalent. For one thing, there's nothing that says a vector can't just
decide to up and make an "extra" internal copy of some object it
contains. For another, when you call generic functions that will copy
elements, like sort() does, the functions have to be able to assume that
copies are going to be equivalent. At least one popular sort internally
takes a copy of a "pivot" element, and if you try to make it work on
auto_ptrs it will merrily take a copy of the pivot auto_ptr object
(thereby taking ownership and putting it in a temporary auto_ptr on the
side), do the rest of its work on the sequence (including taking further
copies of the now-non-owning auto_ptr that was picked as a pivot value),
and when the sort is over the pivot is destroyed and you have a problem:
At least one auto_ptr in the sequence (the one that was the pivot value)
no longer owns the pointer it once held, and in fact the pointer it held
has already been deleted!

If you want to use smart pointers inside containers, use
boost::shared_ptr from http://www.boost.org/libs/smart_ptr/index.htm


Kind regards


B.
Click to expand...
 
Back
Top