Problem :

I'm now working on transferring enemies from a vector of classes called queued_enemies to a vector of classes that looks exactly like the class containing the processed enemies called enemies.

vector<enemy> queued_enemies;//queued enemies.
vector<enemy> enemies;//processed enemies.

when a condition between a value in the queued_enemies vector and a value representing level progress is equal they trigger a set of functions which does the following:

  game::enemies::enemies.push_back(enemy(
  game::enemies::queued_enemies[enyNR].visual,
  game::enemies::queued_enemies[enyNR].Xpos,
  game::enemies::queued_enemies[enyNR].Ypos,
  game::enemies::queued_enemies[enyNR].Xspeed,
  game::enemies::queued_enemies[enyNR].Yspeed,
  game::enemies::queued_enemies[enyNR].Xacc,
  game::enemies::queued_enemies[enyNR].Yacc,
  game::enemies::queued_enemies[enyNR].SpawnTime,
  game::enemies::queued_enemies[enyNR].mov_progress,
  game::enemies::queued_enemies[enyNR].mov_scheme
  ));
      
  game::enemies::queued_enemies.erase(game::enemies::queued_enemies.begin()+enyNR);

What I'm doing(trying to do) is that I'm moving an element from one vector to another.
but for some reason i get REALLY strange results.. as strange effects from bitmaps
used by enemies created this way, i can't understand why the enemies created this way acts so strangely. if the data passes correctly it should be acting correctly! :S.. I'm totally lost, and this time i really mean it..

any suggestions on a better way of transferring elements?

another problem is that the following condition:

if(game::enemies::queued_enemies[enyNR].SpawnTime == game::progress*1000)

which triggers the functions i mentioned above doesn't work! , i'm thinking that maybe SpawnTime is equal to 0 or NULL but it can't be 0 and i don't know the effects of NULL. trying to check a value from an element that doesn't exist would result in a crash right?

The condition isn't used of course.

I'll upload and answer to anything that would help with solving this!
THANK YOU VERY MUCH!!!

Probably because i didn't know of any copy constructor... - -. what is the copy constructor?

YES SIR!..

hmm, i would if i could but i can't figure out what could be relevant and not, here's everything i could think of:

this section is supposed to handle all the events of the level such as spawning and such..

    if(sys::console::input == "NEW TEST A                                ")
    {
     game::enemies::queued_enemies.push_back(enemy(3, 200, -100, 0, 0.012, 0, 0, 7000, 0, 0));
    }

Adding to the quene using the horrible bad excuse called "console" that i'm using to test stuff.

    if(sys::console::input == "NEW ENEMY D                               ")
    game::enemies::enemies.push_back(enemy(3, 200, 100, 0, 0.001, 0, 0, 0, 0, 0));

Adding enemies to the processed enemies. adding enemies the 'normal' way.
this way work perfectly.

need even more? this is pretty much everything concerning the transfer.

Every class has these methods, even if you don't explicitly declare and define them.

class Enemy
{
public:
    Enemy(); //default constructor
    Enemy(const Enemy& o); //copy constructor
    ~Enemy(); //default destructor

    Enemy& operator=(const Enemy& rhs); //copy assignment operator
};

Okay, took some time to soak in the code you posted.

First impression: It's a crime against programming.

Second impression:

I bet the graphical problem is that you release the sprite in the destructor, which is called when you erase the enemy from the queued vector. However, the copy in the enemies vector has a copy of the pointer, and therefore points to the memory you just kersploded!

Store pointers in the vectors, not the objects themselves. But don't use naked pointers, use a smart pointer like the shared_ptr from Boost.org. Or the TR1 smart pointer (whatever it's called), if you like it better for some reason.

The shared_ptr keeps track of how many pointers are referencing it and when the last pointer is gone, it calls the destructor of whatever it points to. This is handy because you don't have to worry about the messy destructor problem with the sprite data, but it still cleans up after itself when you .erase() it.

Use .at() instead of [], .at() does bounds-checking.

Check out iter_swap()

It calls one copy constructor and two operator= assignments.

That ought to be cheaper than calling .erase(), ~Enemy(), Enemy(), and push_back()

At least, I think so.

Edit: Also, don't use for (int i ...) loops with vectors, use iterators in the form of:

for (std::vector<Enemy>::iterator i = enemies.begin(); i != enemies.end(); i++)
{
    //do stuff
}

Just be careful about using .erase() in it. If you use .erase(), do it like this:

for (std::vector<Enemy>::iterator i = enemies.begin(); i != enemies.end();)
{
    if ((*i)->KillMe())
        i = enemies.erase(i);
    else
    {
        //do stuff
    }
}

Note that, when using this form, you don't need to check the size of the vector, because if it is 0, i will be equal to enemies.end() and will bail out immediately.

Phew. How come I've been helping people all day, but my ONE topic has 2 replies, one of which is from me?

Oh yeah, I forgot you were also removing and adding... uh, I've never tried it, but maybe swapping with .end() might work if the STL has a certain element of magic to it. But probably not.

Best bet is to make the super-cheap move of copying the pointer over, then erasing it from the original vector.

Bounds-checking is to make sure you don't try to access something that doesn't exist ie. isn't in the vector. Really just a habit thing.

Then we NEED MOAR KODE!

Point to a dynamically-allocated object.

typedef boost::shared_ptr<Enemy> EnemyPtr;
EnemyPtr p = EnemyPtr(new Enemy());

A naked pointer is just a type and a memory address. A smart pointer keeps track of how many pointers are pointing to the data, so shared data doesn't mysteriously disappear. It also calls delete automatically when no more pointers point to the data.