Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 501
  • Last Modified:

auto_ptr problem :(

Hi out there,
I've got a memory leak here and can't stuff it :(

Here's the stripped down code:

typedef std::vector<std::auto_ptr<LicenseInfo> > t_LIVector;

t_LIVector FillVector()
{
t_LIVector v;
auto_ptr<LicenseInfo> LI(new LicenseInfo);
v.push_back(LI);
return v;
}

t_LIVector vLI = FillVector();

The memory allocated for LI is never freed why?
I thoughed the auto_ptr class manages all the clean up.

Tobias
0
SirSmokeALot
Asked:
SirSmokeALot
  • 2
  • 2
1 Solution
 
KangaRooCommented:
You can't use auto_ptr in vector<>. vector<> relies on certainsemantics for assignment and copying of its elements which auto_ptr does, and can not provide.

The semantics for which auto_ptr does not behave 'intuitively' concern copy-assignment:

  T a, b; // objects
  a = b; // a 'becomes' b, without affecting b. This is not so for auto_ptr

auto_ptr takes full ownership of it's object and how on earth would you implement that with assignment? If a takes over then b will no longer be the same as it was before the assignment. If b keeps ownership, then what should a be after the assignment?

From the 97 draft:
=============
2 The  auto_ptr provides a semantics of strict ownership.  After initial
  construction an auto_ptr owns the object it holds a pointer to.  Copy-
  ing an auto_ptr copies the pointer and transfers ownership to the des-
  tination.  If more than one auto_ptr owns the same object at the  same
  time the behaviour of the program is undefined.
=============

The issue of auto_ptr's behaviour seems to have plagued the standards committee for a long time. I'm not sure what the final outcome is.

I considered these weird semantics so much of a problem that I've implemented two different 'auto_ptr' classes. One is how the standard auto_ptr should have been; a sole ownership with copy and assignment disabled (illegal) and a reference counted shared ownership, which does allow copying and assignment.
0
 
nietodCommented:
>> The issue of auto_ptr's behaviour seems to
>> have plagued the standards committee for a
>> long time. I'm not sure what the final
>> outcome is.
This weird--I would say nearly useles--form was the final decission.  I can't understand why it would have been hotly debated.  There is really only one clear choice, and it isn't this one.  :-)

But, as kangaroo said, you can write a reference counting autopointer class that will work with any STL container.

Typically the reason one doesn't use reference counting is that the object the pointer points to must store a reference count which means that it has to be a struct/class and it has to have some well-defined properties, which means you cannot use the reference counting pointer with the basic types (char, int...) or with class types that were written without these properties (like from a commercial library).  However, it can be done.  You simply store the reference count in a 2nd dynmically allocated memory location.  So the smart pointer class must maintian two pointer data members.  a pointer to the reference count and a pointer to the object that the smart pointer acts like a pointer to.  
0
 
KangaRooCommented:
Can be implemented different. One class of owning objects keeps the counter and the link to the managed object. The visible smart pointer objects stores only one pointer to a shared owner object. The implementation nietod gives uses one less indirection, so it is a very tiny bit faster, but uses more memory; two pointers in each smart pointer object. But that is all rather insignificant.

0
 
nietodCommented:
Actually the method you suggest is more like what I use.  I was just trying to keep it simple.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now