Re: [Boost-users] [SmartPtr] Memory Leak Perhaps

Subject: Re: [Boost-users] [SmartPtr] Memory Leak Perhaps
From: Hossein Haeri (powerprogman_at_[hidden])
Date: 2010-09-20 08:32:21

Hi Binglong,

> Why do you need to use two semantically different pointers
> to point to the same piece of dynamic memory?

I actually don't need to have TWO pointers to the same location. ANY pointer to that location suffices. The reason why I use "this" for that purpose is that the client code calls a virtual function of the class through the pointer that I allocate (using new), and the actual insertion into the container happens from inside this virtual function.

It is of course possible to change the design a bit so that the virtual function also takes the address (of my manually allocated memory) as an argument. However, I would be interested to know which exact difference between the semantics of ordinary pointers and "this" might be making the trouble here. Could you be more precise please?

> The client creating the instance
> should probably manage the life cycle of this instance.

Sure. And, that's why I store smart pointers in my container.

> I would say it's normally the responsibility of the client to
> put the instance pointer into a shared_ptr if it's not
> allocated on the stack.

Although this is possible indeed, I believe it would involve making my design a bit messy. See below.

> Again, you may want to paste your
> code to make the discussion easier.

OK, nice suggestion.

I have a hierarchy H of classes with the base B, where B* need to be stored in a container. Insertion of B*'s into my container needs non-trivial processing prior to their actual addition to the container. These pre-processings differ from class to class in the hierarchy. In order to manage this complexity thus, I have broken the pre-processing down into chunks. Each individual class in H handles its own entire insertion (including the pre-processing and the actual insertion). This is done via implementations of:

virtual B::insert_me_into(container&) = 0;

where classes derived from B have enough access to the container through some protected interface toolkit provided by B.

Thanks,
--Hossein