Hello, my program keeps crashing all the time. The VC10++ debugger won't help me either. In my main I create a Player class and a Game class to handle logic.
And when I get into the game loop it sometimes crashes instantly, but often not. I send the address of the player class and an array of Platform classes to the game.update to do collision detections and other stuff.
The crash happens inside game.update at the player->move(&events);

main.cpp

game.h

game.cpp

Player.cpp

player.h

the here's the Pistol.h

Pistol.cpp

And the bullet class is quite small, so I doubt that's the problem but here it is anyways.

bullet.h

bullet.cpp

Oh the number 12 comes from magazineSize variable, forgot to edit that. I want all of the bullets to be separate objects, also when a bullet hit something it would get destroyed I just haven't gotten to that part yet.

But why is an array of objects a bad idea? The array size would be different depending on how big the magazine was, I had a for(int i = 0; i < magazineSise;i++) which would check if bullet[i] was already active, if it was then it would continue until it found one not active and create one there.

The reason I want the bullets to be objects is that it would make it easier to mess with them when they're in the air, also I will be adding different types of damage and other fun stuff.

The debugger did help me a bit, and I did learnt to use it a bit better the hours I've been trying to fix the crash. Thank you for your help, but it would be really helpful if someone would elaborate why it is a bad idea to use object array, was it because of the memory leak and if I fired more bullets than there was size for in the array?

I've never tried to have a class create an instance of some other class in the constructor, is that different in any way? I've used object arrays before and they've never been a problem before.

void Pistol::fire()
{
  if(!bullets[bulletsShot]->isActive)
  {
    bullets[bulletsShot] = new Bullet(bulletVelocityX, bulletVelocityY, bulletType);
    calcDamage(bullets[bulletsShot]->mass);
    std::cout << "Bam!" << std::endl;
  }
  bulletsShot++;
};

This code could easily lead to out-of-bounds array access and cause memory corruption, which would result in the random crashes you've described. Add a check to make sure 'bulletsShot' is in the valid range.

There's nothing technically wrong with using arrays of objects or object pointers, but arrays in general can lead to bugs that are notoriously hard to track down because they let you silently corrupt memory if you're not careful. It may lead to random crashes at random parts of the program that have nothing to do with the source of the bug. As rule of thumb, use vectors unless you have a good reason not to. They offer additional safety and features. Note that vectors have a '[]' operator like arrays, but it doesn't check for out-of-bounds access and is as dangerous as plain array access. Use the 'at' method.

In any case, I think your design isn't optimal. When a bullet leaves the gun, it belongs to the world. The gun shouldn't be responsible for updating the bullet positions or for checking if they collide with anything. It's the job of the world object.

Oh, actually, I see the problem now.
When you create the bullet pointer array, it's filled with garbage. Then you treat that garbage like valid pointers and try to read the 'isActive' field, so you get a segfault.

What you're doing doesn't really make much sense.
Why does the ability to shoot new bullets depend on whether the old ones are alive?
Why are the bullet pointers not stored in a list in the game class with the rest of your objects? The gun has nothing to do with the bullets after they've been created.
If you really must insist to store the bullets in the gun object, why do you need an array of pointers? Just make an array of bullets and mark them all as dead initially. This will prevent your crash.

It depends on whether the garbage pointer happens to point at a location that belongs to your program (in which case you'll read a random number) or another program (that's a segmentation fault and will make you crash).

Now, I don't really understand what you're talking about in the rest of your post, but what I'm trying to say is that a bullet is a game object like any other and should be treated as such. The gun just creates one, adds it to the big list of game objects and forgets about it. If you don't have a Game class yet that holds such a list, you should create one first because everything else depends on it.

If you create an object inside a function without the 'new' keyword, it lives on the stack and dies as soon as you leave the function.

If you create an object inside a function with the 'new' keyword, you hold its address in a temporary pointer that dies as soon as you leave the function. The object itself lives but you can't do anything with it (not even destroy it). This is called a memory leak.

Currently, you keep pointers to the bullet objects you create inside an array that is a member of the Pistol class. This is bad because:

1. The pistol object doesn't need to refer to the bullets, so it shouldn't store pointers to them.

2. The game manager object that needs to refer to the bullets should be able to do that directly, not through the pistol object.

3. You should be able to create and destroy bullets freely, so the proper data type is a list.

In short, you should not store bullet pointers inside an array that belongs to the pistol object. You should store bullet pointers inside a general list of game entities that belongs to some kind of game entity manager.

A quick and dirty fix for your problem would be to create an array of objects, not object pointers.

However, I would strongly advise against actually doing that. It will stop your game from crashing, but it's just a temporary quick fix. Your real problem is a design problem.