Surcharge constructeur !

Version imprimable

Bonjour à toutes et tous,

j'ai simplement une petite question, comment peut-on surcharger un constructeur de cette façon

exemple
Code:

1 2 3 Personnage::Personnage(string epee, int degatsEpee) : m_Vie(....), m_arme(epee, degatsEpee){} Personnage::Personnage(string bouclier, int protectionBouclier) : m_vie(....), m_arme(bouclier, protectionBouclier){}

03/12/2015, 18h01
foetus

Simple :mrgreen:

Code:

Personnage::Personnage(string value_str, int value, bool is_damage) : m_Vie(....), m_arme(value_str, value, is_damage){}

Édit: Simple :mrgreen:

Code:

Personnage::Personnage(string value_str, int value, bool is_damage) : (is_damage? m_Vie(....): m_vie(....)), m_arme(value_str, value){}
03/12/2015, 18h32
white_tentacle

Tu as conscience que tes deux surcharges sont strictement identiques ?

Si tu as besoin de différencier bouclier / épée, peut-être qu’il serait intéressant de les typer plus fortement que simplement avec un std::string.
03/12/2015, 18h34
foetus

Citation:

Envoyé par white_tentacle

Tu as conscience que tes deux surcharges sont strictement identiques ?

Il y a une majuscule :mrgreen: m_Vie au lieu de m_vie

Après faute de frappe ou pas :koi: :koi:
03/12/2015, 19h41
speedy_souris

Faute de frappe !!!

Citation:

Envoyé par foetus

Il y a une majuscule :mrgreen: m_Vie au lieu de m_vie

Après faute de frappe ou pas :koi: :koi:

:P c'est bien une faute de frappe...

speedy_souris a encore frapper :mouarf:

aussi peut etre creuser la piste sur le fait que le bouclier n'est pas une arme mais une protection (a voir autre classe )

Franchement, pour ce genre de jeu, je verrais plutôt une gestion de l'équippement de ce genre:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
enum PlaceEquipement //Note: utiliser "enum class" si supporté
{
	Tete,
	Torse,
	MainGauche,
	MainDroite,
	MAXp1_PLACE_EQUIPEMENT
};
 
struct ObjetEquipable
{
	//Ici, on supporte TOUTES les propriétés des objets,
	//comme ça certains peuvent servir aux deux (bouclier à pointe, épée avec garde, etc.)
	string nom;
	int protection;
	int degats;
};
 
class Personnage
{
private:
	vector<ObjetEquipable*> equipement;
	bool estGaucher;
public:
	Personnage(bool estGaucher) : equipement(MAXp1_PLACE_EQUIPEMENT), estGaucher(estGaucher) {  }
 
	void equipe(PlaceEquipement place, ObjetEquipable* objet) { equipement.at((int)place) = objet; }
 
	ObjetEquipable const * getArme() const
	{
		return estGaucher ? equipement.at((int)MainGauche) : equipement.at((int)MainDroite);
	}
	//Ensuite, pour la protection, un truc de ce genre, ou de l'autre:
	int getSommeProtections() const
	{
		//Note: En fait, il doit y avoir un truc dans <algorithm> qui fait ça pour toi
		int total = 0;
		for(vector<ObjetEquipable*>::const_iterator it = equipement.begin() ; it != equipement.end() ; ++it)		
		{
			if((*it) != null)
				total += (*it)->protection;
		}
		return total;
	}
	ObjetEquipable const * getMeilleureProtection() const
	{
		//Note: En fait, il doit y avoir un truc dans <algorithm> qui fait ça pour toi
		ObjetEquipable const* meilleur = null;
		for(vector<ObjetEquipable*>::const_iterator it = equipement.begin() ; it != equipement.end() ; ++it)		
		{
			if((*it) != null)
			{
				if(meilleur==null || (*it)->protection > meilleur->protection) 
					meilleur = *it;
			}
		}
		return meilleur;
	}
};

07/12/2015, 15h12
koala01
Salut,

Pour la surcharge de fonctions, il y a deux règles simples à respecter:
1. le nom du paramètre n'a aucun intérêt pour le compilateur (il se foutra pas mal de savoir si le premier paramètre s'appelle bouclier ou épée ;) )
2. pour chaque surcharge, il faut au moins une différence par rapport au autres; soit au niveau du nombre de paramètres, soit au niveau du type d'au moins un des paramètres attendus.
Ton exemple ne respecte pas la règle (2) et les noms tombent sous le coup de la règle (1). ==> Raté... Try again ;)
10/12/2015, 05h12
Pierre le Grand

Je ne suis pas étranger au domaine du jeu de rôle ayant écrit et dirigé le scénario de tournoi utilisé lors du tournoi d'Appel de Chtulhu de réanimation 95 à Montréal.

Votre constructeur comporte une erreur de conception flagrante. Un personnage et son équipement sont deux entités distinctes qui évoluent de manière distinctes dans les temps. Si un personnage lieutenant de police tombe à zéro point de santé mentale, son arme et sa carte de police devront lui être retirées durant son traitement. Si le lieutenant meurt en service, tout son équipement tombera au sol et pourra être récupéré par les autre PJ ou par un PNJ. Le personnage peut mourir et l'équipement survivre. Un personnage peut vivre mais son équipement peut être perdu, devenir défectueux, être endommagé. L'équipement peut changer de propriétaire.

Un type énuméré limiterait l'équipement de manière inacceptable. Même après la réalisation d'un moteur de jeu de rôle, on doit être en mesure d'ajouter une pièce d'équipement sans toucher au moteur d'où l'importance d'utiliser une hiérarchie de classes pour l'équipement et des patrons de conception appropriés pour la création. En fait, l'équipement se prête de façon idéale à l'orientation objet, les règlements du jeu de rôle classent déjà l'équipement en catégorie: par exemple armes à feu qui contient armes de poing, armes longues et armes de guerre, armes blanches qui renferme dagues, épées, armes d'hast...
10/12/2015, 06h19
Médinoc

Citation:

Envoyé par Pierre le Grand

En fait, l'équipement se prête de façon idéale à l'orientation objet, les règlements du jeu de rôle classent déjà l'équipement en catégorie: par exemple armes à feu qui contient armes de poing, armes longues et armes de guerre, armes blanches qui renferme dagues, épées, armes d'hast...

Attention, cela se prête en fait mal à une hiérarchie de classes. Par contre, un système de "tags" ou de classes de traits pourrait être approprié...