From: Daniel Krügler on
On 15 Jul., 14:03, dailos <dailos.guerr...(a)> wrote:
> I am struggling with a design problem. It showed up because of some
> architectures constraints.
> I have a group of classes which derive from an abstract one.
> I have a vector with pointers to the generic abstract class (neither
> vector of references nor vector of classes are allowed since it's
> abstract).
> A member function that loads objects into the vector, lets say from
> file, has to do it creating object with new operator since it couldn't
> be done by references to objects created locally.
> A public functions lets the user to add single objects too but it
> could use new or reference as an argument.
> The problem is when I need to call the destructor, and erase all of
> the objects created within the vector.
> I thought of using delete operator for each element in the vector, but
> what if some other elements has been added from a reference. delete
> &something ## failure.
> I guess there is no way to distinguish between object address created
> with new and created with a reference.

This is correct, the language / standard library does not provide
a discrimination for these differently created objects.

> How a to write a proper destructor then??

If you have decided for a design exactly based on

std::vector<Fruit*> fruitList;

and the member function

void addFruit(Fruit* pFruit);

you have no other choice: You must require that the user satisfies
your contract that only object valid pointers generated by non-array
new are provided to that member function.

If you are free to refactor your design you might want to consider to
change to

std::vector<shared_ptr<Fruit> > fruitList;


void addFruit(const shared_ptr<Fruit>& pFruit);

where shared_ptr<Fruit> is either of boost::shared_ptr<Fruit>
or std::(tr1::)shared_ptr<Fruit>. These shared_ptr classes
allow users to provide the appropriate deleter. It will work with
either Fruit objects allocated by new or with Fruit objects
allocated in any other feasible way.

HTH & Greetings from Bremen,

Daniel Kr�gler

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Tonni Tielens on
{ A little more quoting would be nice. :) -mod }

On 15 jul, 14:03, dailos <dailos.guerr...(a)> wrote:
> ...

Apart from the implementation difficulties, you have a design problem
here. Either the Basket object takes over memory ownership for the
Fruit objects or it doesn't. Memory ownership in general results in
hard to track defects, but differing in memory ownership in a single
collection is even more tricky. I would invest in a solution where the
Basket object either completely owns all of the Fruit objects or it
doesn't. So for instance, try using 'new' in your main (or similar
function in your real program) too.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]