Thread: delete objects

Hi everyone,

im getting a signal 11 error message when i try to run this code...

can anyone see why..

Code:

void printContainer (vector<Shape*> &s) {

	int counter=1;
	
	for (vector<Shape*>::iterator i = s.begin(); i != s.end(); counter++, ++i)
		cout << "Shape " << counter << " area: " << (*i)->area() << endl;		

	for (vector<Shape*>::iterator j = s.begin(); j != s.end(); ++j)		
		delete (*j);
}

i figured out the problem...i had objects that were not on the heap...hence i was trying to delete objects on the stack...

i was calling this function like this...

Code:

int main(void) {
	
	vector<Shape *> shapes;
	
	Square s0(42,1);

	Shape *s1 = new Square(2,4);
	Shape *s2 = new Circle(2,4);
	Shape *s3 = new Triangle(2,4);
	//Shape *s4 = &s0;
	
	shapes.push_back(s1);
	shapes.push_back(s2);
	shapes.push_back(s3);
	//shapes.push_back(s4);

	printContainer (shapes);

	return 0;
}

is there anyway to tell if i need to delete an object or not from a container...

say in a container i have objects on/off the heap...and obviously i only want to delete the objects that are on the heap...can i do that?

Originally Posted by mitakeet

There is no way to know just by looking at an object if it has been allocated on the stack or heap unless you want to delve into the arcana of address location

It is, however, possible to implement a class with sufficient intelligence so objects can be asked whether they were allocated dynamically or not.

For example;

Code:

//   code not tested:  intent is to ilustrate approach

#include <new>   // for size_t and default operator new()

class DetectOnHeap
{
     public:

           void *operator new(std::size_t);
           DetectOnHeap();

           bool OnHeap() const;

    private:
           bool on_heap;
           static bool test_on_heap;
};

bool DetectOnHeap::test_on_heap = false;

void *DetectOnHeap::operator new(std::size_t size)
{
    // we do things in this way for exception safety
    void *allocated_memory = ::operator new(size);
    test_on_heap = true;
    return allocated_memory; 
}

DetectOnHeap::DetectOnHeap()
{
     on_heap = test_on_heap;
    test_on_heap = false;
}

bool DetectOnHeap::OnHeap() const
{
     return on_heap;
}

The above won't detect objects created with other forms of operator new (eg operator new[] or placement new), and is not thread safe.

... so mix with the memory management libs, and get the upper and lower address.

Then you'll have lots of work and trouble, for some useless heap cheking.
Skip the stack vars, and use always the heap

Originally Posted by xErath

Skip the stack vars, and use always the heap

That just gives another set of potential problems (eg forgetting to clean up variables on the heap).

Originally Posted by CornedBee

So use smart pointers!

Simple answer, but life is rarely that simple.

Smart pointers involve several trade-offs and restrictions on how you use them as well. For example, std::auto_ptr cannot be used in the standard containers (std::vector, etc). There are more advanced smart pointers around, but they impose other design restrictions.

Bottom line is that object lifetime is a critical element of any system design. And simple answers (eg only use the heap, only use smart pointers vs only use the stack) only work in some cases but not others.

And don't even get me started on the trade-offs of garbage collection.... another good capability (albeit one not forced on C++ programmers) but one that involves several costs if misused.

Originally Posted by grumpy

That just gives another set of potential problems (eg forgetting to clean up variables on the heap).

No.. He'll simply have to clean all objects, and dispose of the error prone stack checking...

Originally Posted by xErath

No.. He'll simply have to clean all objects, and dispose of the error prone stack checking...

Simply?

Given the number of times this sort of problem catches out both novices and experts, I would hardly describe it as "simple".

In a very small program that might be easy. As the program gets larger, it becomes more challenging to manage object lifetime. In a program of moderate size (by which I mean less than a man year to develop) it is not so easy. In a large program (developed by a team, and several man years of effort involved) it takes quite a bit of effort to ensure that all objects are cleaned, and error prone checks are either eliminated or corrected.