delete objects

This is a discussion on delete objects within the C++ Programming forums, part of the General Programming Boards category; Hi everyone, im getting a signal 11 error message when i try to run this code... can anyone see why.. ...

  1. #1
    Waxy-Dock
    Join Date
    Mar 2005
    Posts
    69

    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);
    }

  2. #2
    Waxy-Dock
    Join Date
    Mar 2005
    Posts
    69
    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?

  3. #3
    Registered User mitakeet's Avatar
    Join Date
    Jun 2005
    Location
    Maryland, USA
    Posts
    212
    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.

    Free code: http://sol-biotech.com/code/.

    It is not that old programmers are any smarter or code better, it is just that they have made the same stupid mistake so many times that it is second nature to fix it.
    --Me, I just made it up

    The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.
    --George Bernard Shaw

  4. #4
    Skunkmeister Stoned_Coder's Avatar
    Join Date
    Aug 2001
    Posts
    2,572
    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.
    Free the weed!! Class B to class C is not good enough!!
    And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote 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.

  6. #6
    #include<xErath.h> xErath's Avatar
    Join Date
    Jun 2004
    Posts
    722
    ... 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

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote 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).

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    So use smart pointers!
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote 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.

  10. #10
    #include<xErath.h> xErath's Avatar
    Join Date
    Jun 2004
    Posts
    722
    Quote 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...

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    Quote 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.

  12. #12
    #include<xErath.h> xErath's Avatar
    Join Date
    Jun 2004
    Posts
    722
    Quote 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
    Last edited by xErath; 07-03-2005 at 05:17 PM.

  13. #13
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    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.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  14. #14
    Skunkmeister Stoned_Coder's Avatar
    Join Date
    Aug 2001
    Posts
    2,572
    Free the weed!! Class B to class C is not good enough!!
    And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi

  15. #15
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    I was asking about examples of design restrictions, not smart pointers
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Cannot delete objects
    By theJ89 in forum C++ Programming
    Replies: 7
    Last Post: 03-30-2006, 09:25 PM
  2. delete and delete []
    By Lionel in forum C++ Programming
    Replies: 8
    Last Post: 05-19-2005, 01:52 PM
  3. Problem need help
    By Srpurdy in forum C++ Programming
    Replies: 1
    Last Post: 07-24-2002, 12:45 PM
  4. memory management...
    By master5001 in forum Game Programming
    Replies: 24
    Last Post: 01-07-2002, 04:50 PM
  5. how to delete objects
    By Unregistered in forum C++ Programming
    Replies: 4
    Last Post: 08-31-2001, 02:06 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21