Re: auto_ptr compile error
Tamas Demjen wrote:
I would like to add that you have to be very careful with auto_ptr.
Ironically, it leaks sometimes (on Visual Studio 2005 and other
compilers as well). Yes, you heard it right, you can get into serious
trouble with it.
Well, there is one danger, and that is to use the returnvalue of release()
without paying attention to the transferred ownership.
class Thing;
class Owner
{
public:
Owner();
private:
std::auto_ptr<Thing> thing;
};
Wrong. You must not instantiate auto_ptr on incomplete types. Anything that
follows is just useless speculation about the behaviour of one
implementation when it is operating outside the guarantees of the standard.
- Forward declaration only works well with auto_ptr if you define a
destructor in the .cpp file, even if it's an empty one.
"work" != "is guaranteed to work"
- Rule of thumb: If a class has any auto_ptr member, the class shall
have an explicit destructor defined in the .cpp file.
Nonsense.
- Compiler warnings must be taken seriously, especially if they refer to
the type "auto_ptr", because it tends to leak.
Every compiler warning should be taken seriously and, before deactivating
it, should be understood thoroughly.
- Consider using boost::scoped_ptr, because it has a truly ingenious
trick to verify this bug at compile-time. It generates a real error
message out of it, using the helper class boost::checked_delete.
scoped_ptr simply wouldn't let you compile my original example. I wish
auto_ptr used checked_delete too. Hopefully in C++0x.
Well, it could do that, it's an implementation detail, but as long as people
then complain that it breaks their code which relies on undefined behaviour
(like yours above) it will be hard to introduce that. I'd be all for it.
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932