a good idea might be to make the projectile a class aswell. and let it have its own update methods, damage rating, etc.
thus the weapon simply creates a new projectile at a set position and direction, and possibly sets the starting speed. after that your game can just treat the projectile as any other entity.

a good idea might be to have a base entity class aswell that has an abstract update method, and stores the position etc. then the game simply has to loop through a list of entities, run their update methods and so on.
the projectile class would then inherit from entity, the player and enemies would ofcourse also inherit from the entity class. and ofcourse you can push it even further and have a rocket class that inherits from projectile and so on.

i did an attack class and i just did

#define playerleft 1
#define playerright 2
#define playerup 3
#define playerdown 4


then like

if(Player.Status == playerleft)
{
rocket.x += xVel;
}
else if(Player.Status == playerright)
{
rocket.x -= xVel;
}

That's a good start. Let me make a couple of points :
I think that a weapon should be derived from a more basic class that only has update, create, destroy.
why? : It lets you later derive a Rocket class and have a Fire() method ,-it shoots .., but more importantly, you can derive somthing like Sword without Fire() but maybe with Swing(), or Rock with Throw().

So what it boils down to is, it takes 2 minutes to code a most basic base class, or forget about other weapons, and have firing weapons ...

If you decide to split them apart , i would suggest:

class Thing {
private:
posx, y, z ...
public:
constructor, destructor ...
Init();
Update();
Destroy();
}

class Projectile derived from Thing {
velx, vely, velz ...
damage, sprite, other stuff
public:
BlowUp();
....
}

class Weapon derived from Thing{
array of Projectiles ...
public:
fire();
....
}

This design has issues, but it does split up the major differences while keeping it quite simple.

g'd luck