I have a vector that is holding pointers to 7 objects, but my destructor does a single delete and stops. Even live debugging it just gets stuck at the first delete.
Vector of Object pointers: std::vector<Comparable*> compareVec;
Do you have a copy constructor and copy assignment operator for HighScore? How are the elements allocated? If there is an inheritance tree and Comparable is at the top, does it have a virtual destructor?
The destructor just hangs, so when I click f5 it will cout comparable destructor, but thats it... doesnt exit, doesnt cout object pointers deleted or anything.
No copy constructor or anything special, I just make the objects and push them in as pointers. Like so:
(1) ordinary delete
Deallocates the memory block pointed by ptr (if not null), releasing the storage space previously allocated to it by a call to operator new and rendering that pointer location invalid.
Lets recap: HighScore is a Comparable. HighScore has a list of Comparables. On destruction, a HighScore object destroys the other Comparables that it has in the list.
Who are those other Comparables? Where did they come from? What side-effects does their destruction cause?
Most importantly, what does the pushObjectVector do?
So unless I use keyword "new" the objects will be on the stack?
This project is supposed to sort the objects inside the vector based on their values, first by the score then if both obj 1 and 2 have the same score then sort by name.
I'm still not sure how to fix it, since vectors clear whats inside them automatically but the pointers remain.
So unless I use keyword "new" the objects will be on the stack?
We don't have the context of your object definitions (and C++ doesn't have any concept of a stack in this sense.) They may be objects with automatic storage duration. What they won't be is objects whose addresses you may feed to delete.
I'm still not sure how to fix it, since vectors clear whats inside them automatically but the pointers remain.
Simple enough: don't delete them. But, why should a HighScore contain a vector of Comparable* and why does Comparable have such a bloated interface?
edit:
why are you dereferencing the iterator and deleting objects that have no memory allocated to them?
delete *it;
your objects are not allocated on the heap.
what you really have is this
1 2 3 4 5 6 7 8 9 10 11 12 13 14
compareVec[0] = c1("one", 33);
//what you need is
compareVec[0] = new c1("one", 33);
//or
HighScore *c1 = new HighScore("Lawrence", 2300);
oManager.pushObjectVector(c1);
//why should oManager delete c1?
//it is not instantiated inside the oManager instance
compareVec[0] = c1("one", 33);
//what you need is
compareVec[0] = new c1("one", 33);
No, that's not what he really has and it's not clear that's what he needs. c1 is an object, not a class. Were you to use the name of the class, line 1 would still be in error. Were you to additionally take the address of the temporary created thusly, you still would not be correct.
I got confused after looking at his code, what I meant to say was it looks like he is passing in the C1 objects to the vector in the oManager object and trying to free the memory of the C1 objects in the oManger destructor.
no, c1, c2, ect.... should not be deleted inside the oManager instance of the highscore class because they were not allocated memory inside that oManager constructor, so it should not be deletd in that destructor. if you allocate memory for them in Main they should be deleted in Main.
no, c1, c2, ect.... should not be deleted inside the oManager instance of the highscore class because they were not allocated memory inside that oManager constructor, so it should not be deletd in that destructor. if you allocate memory for them in Main they should be deleted in Main.
This is patently untrue. The "owner" of the object is responsible for determining its lifetime, regardless of where it began and it is, in fact, common practice to begin a lifetime prior to the "owner" gaining possession of said object.
This is patently untrue. The "owner" of the object is responsible for determining its lifetime, regardless of where it began and it is, in fact, common practice to begin a lifetime prior to the "owner" gaining possession of said object.
Yes, you are right but, in his case wouldn't it be better not to? The code looks like its all over the place, he said he want's to understand the basics first. I am guessing he has a vector of *Comparable because he wants to use polymorphism. I was just saying that he should clearly separate the code he is using and get reorganized because it looks like he is trying to learn the basics by using pointers for dynamically allocated memory, polymorphism, and passing by reference in one project. I think that it is too overwhelming for someone who needs to learn the basics first. I would say before fixing his destructor go and put comments in your code before racing back and forth to fix a bug because you will be trying to read code at 100 mph and debug at the same time while flipping back and forth.