1 constructor, 2 destructor!

This is a discussion on 1 constructor, 2 destructor! within the Game Programming forums, part of the General Programming Boards category; Hey everyone, I'm really stumped on this one. This is my code:
Code:
for(i = 0; i < 6; ++i)
...

I cannot say exaclty what the error is, but I can give you an advice:
Instead of indexing with [] right after push_back, use vector<>::back() to access the element at the back.

Btw, why do you have an init() member function instead of a constructor?
You could have a vector of pointers and code something like this:
fighters1.push_back(new Ship(gfx, (float)i * shipSpace, 1000));

Fordy is correct. Copy constructors are generated automatically if not provided. Try removing the copy constructor from his code.
You should provide copy constructors to your classes.

One good way to structure your program is to make an abstract base class called Object and derive different enemies and objects from it.
Then use a global vector<Obejct*> to hold every object in the game. You can process each object using a virtual method called process() or something.

If that is too advanced, just turn the vector into vector<Ship*>. That will remove the above problem and decrease overhead.

Oh, ok Never thought of the copy constructor. I'll try doing the derive-all-from-Object on my next project, but this one is already too complicated and screwed up for me to re-structure it at this point I guess I'll try out the Ship* for the time being, and hope it'll work as a quick-fix... But somehow, I get this evil feeling that it was Ship* before and I changed it to Ship to fix some other bug... Oh well, thanks anyways

"...the results are undefined, and we all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' faces." --Scott Meyers

Persoanlly I try to avoid stl containers of pointers........it's a pain in the butt to manage memory freeing....Where possible I prefer to use the object itself (and have the container become resoponsible for allocating the memory) or maybe use a basic smartpointer that will ensure the memory is freed when the container's destructor goes

All I'm saying, is that if you need to create objects and store references to them in a container, sometimes its better to forget storing just the references and to allow the container to create the objects

For instance in the above, you have an extra temporary object being created and destructed when you create the objects using the container.....now for many situations this little ineficiency is worth it because it makes things easier to work with......

It isnt always possible to do this...maybe you need a container of references?.....maybe you need each object to be constructed differently?....