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?

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 (heap and stack have different address spaces, but are NOT guarenteed to be the same location). Either pass in a flag to the function or depend on the caller to handle the deleting.

its really not a good idea to mix stack and dynamic allocation in the same container, especially as there is no portable way in standard c++ to actually work out whether an object was stack,static or dynamically allocated.

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).

So use smart pointers!

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.

Originally Posted by grumpy

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.

I .... glup! (big frog)

He has 3 choices

• clean everything
• pretend that there is a VM and leak everything
• do stupid a error prone memory adress analsys, and if lucky not crash is program when cleaning a object stored in the stack.

any experienced programmer knows this, and will never try such a feat. instead he/she will modularize as much the program to keep small amounts of related code together, to ease resources management.
extra: C++ introduced something called the destructor or deconstructor (whatever) to do cleaning automaticly. classes store classes which store classes (bla bla bla) and each deconstructor call the contained classes deconstructors and what so ever... Big deal. Good structuring is the key

extra: C++ introduced something called the destructor or deconstructor (whatever) to do cleaning automaticly. classes store classes which store classes (bla bla bla) and each deconstructor call the contained classes deconstructors and what so ever... Big deal. Good structuring is the key

That's what CornedBee said: Use smart pointers!

do stupid a error prone memory adress analsys, and if lucky not crash is program when cleaning a object stored in the stack.

Well, you could also just store an extra boolean (or other) variable called 'heap'. Or if there's already a 'flags' variable, just define an extra flag.

Code:

if((*it)->heap)
   delete *it;

There are more advanced smart pointers around, but they impose other design restrictions.

Could you give some examples?

**P.s. I agree with you though, grumpy, that individual cases have individual needs.

boost smart pointers
Or even more complex:- Loki smart pointers

To name just a few.

I was asking about examples of design restrictions, not smart pointers