Thread: Another pointer problem

  1. #1
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114

    Another pointer problem

    Hi, I've got some problem that I can't figure out why it would "do this" that way...
    I have a pointer in a class that I initialize in a constructor, then insde a member function, I allocate to that pointer some 100k of memory. Then I put a destructor with code for releasing that memory, but it fails to delete the pointer... I tried things and I figured out that the operator "delete" would work properly when I placed it in the SAME function where it was allocated with "new"...

    Code:
    class abc {
    	public:
    		int a*;
    		abc() {
    			a = 0;
    		}
    		func() {
    			a = new int[100000];
    			//do stuff...
    		}
    		~abc {
    			delete[] a;
    		}
    };

    But what is wrong with all this? Delete is supposed to work everywhere as long as we have our pointer allocated to something... But I get errors, and while debugging (MSVC), I tried to move the "cursor" right after "a" was allocated, to the line of code inside the destructor to delete a, but not only didn't it deallocated my pointer, but it took even more memory on my RAM . Can someone here help with this strange behaving?

  2. #2
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,273
    >> I allocate to that pointer some 100k of memory.
    Not sure if that's totally correct

    >> func() { ... }
    void funct() perhaps?

    And post the errors

  3. #3
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    Yeah well I know it's just that I forgot but then its sure to have a void!
    Mistake of mine, but I still get the same errors, can you help ?

    Code:
    class abc {
    	public:
    		int a*;
    		abc() {
    			a = 0;
    		}
    		void func() {
    			a = new int[100000];
    			//do stuff...
    		}
    		~abc {
    			delete[] a;
    		}
    };

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Code:
    int* a;
    Also, what do you think will happen if abc.func() is not ran and consequently the destructor gets called on a pointer that was not dynamically allocated?
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    Registered User
    Join Date
    Mar 2002
    Posts
    125
    Quote Originally Posted by Mario F.
    Code:
    int* a;
    Also, what do you think will happen if abc.func() is not ran and consequently the destructor gets called on a pointer that was not dynamically allocated?
    I'm guessing explosions will happen. Either that or skeletons.
    Seeing as the pointer is nicely initialised to 0 in the constructor, mikahell could do a check to make sure it's not still 0 before deleting it.

    Not sure if this is the cause of the problem, but destructors tend to look like ~abc(), not just ~abc. mikahell, maybe it'd be a good first step to see whether your destructor is being called at all?
    Typing stuff in Code::Blocks 8.02, compiling stuff with MinGW 3.4.5.

  6. #6
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    Quote Originally Posted by Boksha
    I'm guessing explosions will happen. Either that or skeletons.
    Explosions? Skeletons? Apparently you don't know the inner workings of programming and black magic. Deleting an unallocated pointer causes mass tornados. Sheesh. Why don't you go to a library and check out The Warlock's Approach to C: Second Edition before you say something else that makes you look ignorant.
    Not sure if this is the cause of the problem, but destructors tend to look like ~abc(), not just ~abc. mikahell, maybe it'd be a good first step to see whether your destructor is being called at all?
    As long as you manage to leave the scope in which the object was created with no problems, then the destructor is called. When you write a program, you should always count on it being called. You were right at the beginning of your post (not about the skeletons... noob) where you said all he has to do is check to see if the pointer isn't null in the destructor. That's what Mario was getting at.
    Sent from my iPadŽ

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    I think we are just dealing with a bunch of typographical errors. If the member variable, member function and destructor are written properly, the code is fine (except that the member variable is public for no discernable reason). Then again, why not go RAII all the way?

    Seeing as the pointer is nicely initialised to 0 in the constructor, mikahell could do a check to make sure it's not still 0 before deleting it.
    No need, delete or delete[] on a null pointer is always safe.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    Quote Originally Posted by laserlight
    No need, delete or delete[] on a null pointer is always safe.
    You sure? I would have thought it was one of many of the undefined conditions in C++. I'll take your word for it.
    Sent from my iPadŽ

  9. #9
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Yes. Delete is always safe on a null pointer.

    However, I was actually asking the OP what was it he intended to do in answer to his question "I tried things and I figured out that the operator "delete" would work properly when I placed it in the SAME function where it was allocated with "new"..."
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #10
    The larch
    Join Date
    May 2006
    Posts
    3,573
    However, what would happen if someone were to call func several times for the same object?

  11. #11
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    Well, my constructor and my destructor all both are called at the right time, and so the constructor or destructor aren't called in reversed order.

    About: "I tried things and I figured out that the operator "delete" would work properly when I placed it in the SAME function where it was allocated with "new"..."...
    I mean that I tried deleting it from several places, and that sometimes it could be deleted, and at other times, it would crash. But it's like if the scope was not right or the delete should be done in the same function were it was "new-ed"...

  12. #12
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    The problem mikahell is that you are calling delete [] on the destructor. This would be fine, if the pointer was allocated in the constructor. But being called inside a member function, you lose control over your allocated memory. The delete should be moved inside the member function. It will work now since you had some bugs in your code that I believe you corrected now.

    Is there any particular reason as to why you only allocate inside func()? Because if not, replace a = 0; with a = new int[100000]; and keep the delete in the destructor
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #13
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    I think anon has a good point: is abc::func() being run more than once? It doesnt matter if you only allocate inside of func() and deallocate in the destructor. But it does matter if you run abc::func() more than once without a delete[] a in between the calls.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #14
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Yes, he put it better than i did.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #15
    Registered User mikahell's Avatar
    Join Date
    Jun 2006
    Posts
    114
    well, my func will be runned more than once, and the allocation is done there because I wanted this function to be a loader function. I tried to keep it simple, but what I do in this function is mainly loading up an image file to a pointer and that pointer to image data must remain in the class until I decide to get rid of the class, or if I want to load some other image. But then if I want to load something else, I need to deallocate the pointer first, so that's why I thought about having the delete[] right before the allocation, but it puzzles me why the delete[] should be linked to the constructor-destructor and not inside the "loader" function.

    Note: the code I have shown is just some heavy simplification of my code, but it features what makes everything buggy, so I though these part of code were more important.

    The delete should be moved inside the member function I tried that too, with what I'm telling you:

    Code:
    class abc {
    	//Declaration for pointer to be kept in the class
    	void function {
    		//delete[];
    		//allocate
    		//load the image and keep it in memory
    	}
    }
    Well it's mostly pseudo-code, but it's just to tell the way I'm seeing things, but really, the NEW must be matched to DELETE in constructor/destructor?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. pointer to pointer realloc problem
    By prakash0104 in forum C Programming
    Replies: 14
    Last Post: 04-06-2009, 08:53 PM
  2. Pointer problem
    By mikahell in forum C++ Programming
    Replies: 5
    Last Post: 07-20-2006, 10:21 AM
  3. towers of hanoi problem
    By aik_21 in forum C Programming
    Replies: 1
    Last Post: 10-02-2004, 01:34 PM
  4. Quick question about SIGSEGV
    By Cikotic in forum C Programming
    Replies: 30
    Last Post: 07-01-2004, 07:48 PM
  5. pointer problem
    By DMaxJ in forum C Programming
    Replies: 4
    Last Post: 06-11-2003, 12:14 PM