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