Classe avec constructeurs multiples

Bonjour à tous.

J'essaie de faire une classe qui contient 2 constructeurs.
Et je veux définir le second constructeur en faisant appel au premier comme suit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class A { public: A(std::vector<int> vec):_vec(vec){}; A(int x, int y){ std::vector<int> vec(2); vec[0]=x; vec[1]=y; A(vec); }; protected: std::vector<int> _vec; };

---

sauf que la ligne "A(vec)" produit l'erreur suivante :

Citation:

---

test.cxx:48:6: error: redefinition of 'vec' with a different type: 'A' vs 'std::vector<int>'
A(vec);

test.cxx:46:21: note: previous definition is here
std::vector<int> vec(2);

1 error generated.

---

Quelqu'un peut-il m'éclairé ?

Merci

Déjà ton code est bizarre :weird:
Pourquoi vouloir créer un temporaire pour initialiser son attribut en se cassant le trognon à appeler un autre constructeur? :koi: :koi:

Code:

---

1 2 3 4

A(int x, int y): _vec(2, 0) { _vec[0] = x; _vec[1] = y; };

---

Et ensuite il me semble que tu ne peux pas le faire, et il faut créer une méthode qui initialise ton vecteur et qui sera appelée dans les constructeurs :mrgreen:

Édit: Que c'est moche les tirets-bas dans les noms des attributs, et d'ailleurs il me semble que c'est déconseillé :whistle:
Moi, je suis extrémiste: je ne précède même pas le nom de mes attributs par "m_" (ni de n'importe quelle autre indication) :mouarf:

Depuis C++11 il est possible qu'un constructeur appel un autre constructeur (possible uniquement dans la liste d'initialisation)

Code:

---

1 2 3 4 5 6 7 8 9

struct S { S() :S(42) {}   S(int i) : i(i) {}   int i; };   S().i == 42

---

Mais il y a encore plus simple: fournir au vecteur les valeurs de départ.

Code:

---

1 2	A(int x, int y): _vec({x,y}) { };

---

Citation:

---

Envoyé par foetus

Déjà ton code est bizarre :weird:
Pourquoi vouloir créer un temporaire pour initialiser son attribut en se cassant le trognon à appeler un autre constructeur? :koi: :koi:

---

Même si ici ce n'est pas très bien appliqué, c'est très commode comme technique .

Citation:

---

Envoyé par foetus

Oui c'est la technique C++11 pour manipuler les temporaires
Mais a 2-3 subtilités cela revient à ce que j'ai dit :mrgreen:: à créer une autre méthode (donc ici swap) et l'appeler des constructeurs et des opérateurs

---

Pas du tout, cela existait bien avant C++11.

Même si « Code < C++11 à l'arrache non testé », ton code est "archi faux".

Citation:

---

Envoyé par foetus

Code:

---

1 2 3 4

protected:   std::vector<int> vec; };

---

---

Par convention (pas du tout obligatoire), j'utiliserais m_vector au lieu de vec.
Pourquoi mettre cette donnée membre en protected ?

Code:

---

1 2	private: std::vector<int> m_vector;

---

Et je mettrais le constructeur par défaut, qui a du sens (à partir de là tout est public) :
C++11

Code:

---

A() = default;

---

C++03

Code:

---

A() : m_vector() { } // A() { } devrait suffire

---

Citation:

---

Envoyé par foetus

Code:

---

1 2 3

A(std::vector<int> init_vec) { swap(init_vec); };

---

---

La liste d'initialisation suffit amplement.

Code:

---

A(std::vector<int> const & vector) : m_vector(vector) { }

---

Citation:

---

Envoyé par foetus

Code:

---

1 2 3 4 5

A(A& init_a) { std::vector<int> copy_vec(init_a.vec);   swap(copy_vec); };

---

---

Le constructeur de copie est généré automatiquement par le compilateur et fait la bonne chose, pas besoin de l'écrire ; mais si on devait le faire, ça serait :

Code:

---

A(A const & a) : m_vector(a.m_vector) { }

---

Là aussi, la liste d'initialisation suffit amplement, en plus si tu comptes utiliser l'idiome copy & swap, utiliser swap dans le constructeur par copie, ferait une boucle infinie (opérateur d'affectation qui appelle le constructeur par copie, qui appelle swap, qui appelle le constructeur par copie, ...)

Citation:

---

Envoyé par foetus

Code:

---

1 2 3 4 5 6 7

A(int x, int y){ std::vector<int> new_vec(2); new_vec[0] = x; new_vec[1] = y;   swap(new_vec) };

---

---

C++11

Code:

---

A(int const x, int const y) : m_vector({ x, y }) { }

---

C++03 (on pourrait faire une fonction qui prend deux entiers et retourne un vecteur avec ces deux entiers pour faire "comme en C++11")

Code:

---

A(int const x, int const y) : m_vector(2) { m_vector[0] = x; m_vector[1] = y; }

---

Citation:

---

Envoyé par foetus

Code:

---

1 2 3 4 5 6

// Parameter: neither pointer nor reference A& operator=(A other_a) { swap(other_a.vec);   return *this; };

---

---

L'opérateur d'affectation est généré automatiquement par le compilateur et fait la bonne chose, pas besoin de l'écrire ; mais si on devait le faire, ça serait :

Code:

---

A & operator =(A const & a) { m_vector = a.vector; return *this; }

---

Si on a une classe un peu plus compliquée, on peut utiliser l'idiome copy & swap

Code:

---

A & operator =(A const & a) { A tmp(a); std::swap(*this, tmp); return *this; }

---

La fonction template std::swap de la bibliothèque standard fait la bonne chose, si ce n'est pas le cas, on la spécialise. Voici une proposition :
On écrit la fonction membre.

Code:

---

1 2 3 4 5

void swap(A & a) { using std::swap; // Pas nécessaire ici, mais c'est une bonne pratique (merci Flob90) swap(m_vector, a.m_vector); }

---

Et voila la spécialisation (c'est une fonction libre).

Code:

---

1 2 3 4 5

namespace std { template <> void swap(A & a, A & b) { a.swap(b); } }

---

Et pour :

Citation:

---

Envoyé par foetus

Code:

---

1 2 3 4

// Parameter: reference void swap(std::vector<int>& other_vec) { vec.swap(other_vec); };

---

---

std::vector<int> n'a pas de fonction membre swap(). Voir ma proposition au dessus.
En fait si -_- (merci foetus).

Citation:

---

Envoyé par Ehonn

C++03

Code:

---

A() : m_vector() { } // A() { } devrait suffire

---

---

Ton constructeur est même totalement inutile : le constructeur par défaut des membres est déjà appelé implicitement.

Citation:

---

Envoyé par Ehonn

Code:

---

A & operator =(A const & a) { m_vector(a.vector); return *this; }

---

---

T'as été un peu vite là, le std::vector n'a pas d'opérateur() qui prend en paramètres un autre vecteur.

Code:

---

A & operator =(A const & a) { m_vector = a.vector; return *this; }

---

Citation:

---

Envoyé par Bousk

Ton constructeur est même totalement inutile : le constructeur par défaut des membres est déjà appelé implicitement.

---

Il est pas utilisé ici pour l'exemple mais c'est souvent pratique d'avoir un constructeur par défaut.
Oui, le constructeur par défaut des données membre est appelé automatiquement mais pas celui des types de bases (ou alors, il ne fait pas la bonne chose). Autrement dit, int i; est différent de int i = int();. C'est pour cela que je préfère écrire explicitement l'initialisation par défaut des données membre (mais cela ne dépend que de moi).

Citation:

---

Envoyé par Bousk

T'as été un peu vite là, le std::vector n'a pas d'opérateur() qui prend en paramètres un autre vecteur.

---

Oups, désolé, copier-coller :s Je corrige, merci :)

Ce que vous dites est vrai, mais vous n'avez pas expliqué pourquoi c'est impossible d'appeler un autre constructeur comme lg_53 le faisait.

La création d'une variable ou d'un pointeur se fait en deux étapes: allocation d'une zone de mémoire (sur la pile, ou sur le tas avec new), puis construction de la variable.

Pour un type primitif, une enum ou une union la construction est simple: rien du tout, c'est à dire valeur arbitraire. (Undefined behaviour pour être précis)
Pour un tableau, la règle est un peu plus subtile, selon ce qui est fourni (ou non) comme initialiseur et comme taille.
Pour un type construit (struct, class), c'est le constructeur qui est appelé (constructeur par défaut s'il n'y a pas d'argument d'initialisation)

Ce constructeur travaille sémantiquement: en deux temps, initialisation des classes parentes et variables membres, puis traitement global.
L'initialisation est faite dans la liste d'initialisation (d'où le nom), et le traitement dans le corps du constructeur.

On ne peut pas appeler un autre constructeur dans ce corps, parce que justement les variables ont déjà été initialisées (tout particulièrement les constantes et les références).

C++11 ajoute la possibilité d'appeler un autre constructeur dans certains cas mais, pour la même raison, dans la liste d'initialisation.


PS: il me semble que pour un constructeur, les types primitifs sont mis à 0.

La réponse est simple: La syntaxe la plus intuitive pour appeler un constructeur hors de la liste d'initialisation est déjà utilisée pour instancier un objet temporaire.

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

A::A(int a) { m_a = a; m_str = "def"; }   A::A(std::string str) { A(42); //Cette ligne ne fait pas ce que tu crois! m_str = str; }

---

La ligne 42 n'appelle pas un autre constructeur, mais crée un nouvel objet temporaire, immédiatement détruit!

---

Mais ce n'est pas le seul problème: Imaginons que tu réussisses à faire ce que tu veux avec un placement new

Code:

---

1 2 3 4 5

A::A(std::string str) { new(this) A(42); m_str = str; }

---

Félicitations, tu viens d'écraser des données déjà initialisées avec d'autres. Aucun destructeur ni opérateur = n'a été appelé, vu que le constructeur compte sur le fait que les données ne soient pas encore initialisées: Félicitations, tu as fait l'équivalent d'un memcpy() en C++. Très mauvais.
C'est pour ça qu'on ne peut appeler un constructeur du même objet que dans la liste d'initialisation. Ou par copy-and-swap.

Ehon, ce n'est pas fair play de chipoter sur les conventions de nommages :mrgreen: (m_vector <-> vec).

Citation:

---

Envoyé par leternel

PS: il me semble que pour un constructeur, les types primitifs sont mis à 0.

---

Que veux-tu dire par là ? Les types primitifs ne sont mis à leur valeur par défaut (zéro la plupart du temps) qui si explicitement ajoutés dans un constructeur. Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream>   struct Roger { int a; int b[10]; };   int main() { Roger r; std::cout << r.a << "\n"; for(int i = 0; i < 10; ++i) std::cout << r.b[i]; std::cout << std::endl; return 0; }

---

Affiche une horreur du genre :

Code:

---

1 2	1964710984 326184197008000419652801178070192327670

---

Mais

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <iostream>   struct Roger { int a; int b[10]; Roger() : a(), b() {} };   int main() { Roger r; std::cout << r.a << "\n"; for(int i = 0; i < 10; ++i) std::cout << r.b[i]; std::cout << std::endl; return 0; }

---

Affiche bien:

Code:

---

1 2	0 0000000000

---

A noter, la syntaxe avec des parenthèses y compris pour l'array, qui est entièrement initialisé à zéro. En C++11, on peut utiliser des accolades à la place des parenthèses.

Citation:

---

Envoyé par jblecanard

Les types primitifs ne sont mis à leur valeur par défaut (zéro la plupart du temps) qui si explicitement ajoutés dans un constructeur.

---

Selon le draft de la norme C++14 :
int i; est une default-initialization qui, pour les types de base, n'initialise pas (§ 8.5.7)
int() est une value-initialization qui, pour les types de base, est traitée par une zero-initialization (§ 8.5.8)

Bref, la norme garantit que int() est 0.

Citation:

---

Envoyé par Ehonn

Selon le draft de la norme C++14 :
int i; est une default-initialization qui, pour les types de base, n'initialise pas (§ 8.5.7)
int() est une value-initialization qui, pour les types de base, est traitée par une zero-initialization (§ 8.5.8)

Bref, la norme garantit que int() est 0.

---

Oui, et c'est bien ce qu'explique jblecanard, si rien d'explicite n'est fait (i.e. constructeur généré par le compilateur, ou absence de l'entier dans la liste d'initialisation), l'entier à une valeur quelconque (default initialization), sinon non. Et que montre son exemple.

Citation:

---

Envoyé par gl

Oui, et c'est bien ce qu'explique jblecanard.

---

Et c'est ce que j'ai expliqué mais sans l'illustrer dans le message #8.

Citation:

---

Envoyé par jblecanard

Les types primitifs ne sont mis à leur valeur par défaut (zéro la plupart du temps) qui si explicitement ajoutés dans un constructeur.

---

Mon message était là juste pour dire que ce n'est pas « zéro la plupart du temps » mais bien « garantit à 0 lors d'une value-initialization » par la norme elle-même.

En effet, merci pour la précision, j'ai justement dit "la plupart du temps" parce que j'avais la flemme d'aller fouiller dans la norme pour voir si c'était bien zéro dans tous les cas :aie:.

Et moi je me suis dit « Attention ! si jblecanard dit « la plupart du temps » , je ferais mieux de vérifier ce que je pensais savoir » ^^

@Ehonn: La manière idiomatique d'utiliser swap c'est de faire un using std::swap; et d'utiliser un appel non qualifié. Ce n'est pas nécessaire dans l'exemple que tu donnes car ta classe n'est pas template, mais sinon ça le serait (donc autant le faire tout le temps).

PS: Faute de frappe dans ta spécialisation de swap, c'est A pas T à priori.

C'est corrigé, merci :)

Fiou, vous m'en avez donné de la lecture !

Merci pour vos réactions.
Alors pour répondre au mieux à un peu tous le monde:
1) Mon ECM est peut-être en effet trop minimaliste, puisque dans ce cas je peux effectivement procéder par liste d'initialisation du style:

Code:

---

A(int const x, int const y) : _vec(2) { _vec[0] = x; _vec[1] = y; }

---

ou

Code:

---

A(int x, int y): _vec({x,y}) {};

---

Dans mon cas le problème est plus complexe, et je ne peux pas écrire mon second constructeur en faisant seulement une liste d'initialisation...
Je vais peut-être travaillé sur un exemple un peu plus complet, qui s'approcherais un peu plus de ce que j'ai...

2) Vous avez réalisé une petite digression sur la différence entre une default-initialization et une value-initialization. Je me serais cultivé une fois de plus, mais là n'est pas le coeur du problème je pense.

3) Pour ce qui est du swap&copy, vous n'avez pas l'air tous d'accord sur la bonne manière de procéder, mais de toute façon si je travaille avec une structure plus complexe qu'un std::vector, ça semble laborieux à mettre en oeuvre.

4) Pourquoi mettre en protected plutôt qu'en private? C'est un choix personnel. Tout simplement parce que si qqn n'a pas les droits pour modifier la classe mais qu'il souhaite l'améliorer,l'étoffer pour ses propres besoins, et bien il peut faire une classe fllle et a ainsi accès aux attributs librement en lecture et écriture. Là non plus, ce n'est pas ce qui me pose problème.

Pour finir, je code en C++11.

Voici un exemple plus complet, sur lequel je l'espère vous verrez mieux mon objectif.

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

template < typename T > class Box { public: Box(const std::vector<T>& A, const std::vector<T>& B):_A(A),_B(B){}; Box(T ax, T ay, T bx, T by):_A(2),_B(2){ _A[0]=ax; _A[1]=ay; _B[0]=bx; _B[1]=by; }; Box(const Box& box):_A(box.GetA()),_B(box.GetB()){};   std::vector<T> GetA() const {return _A; }; std::vector<T> GetB() const {return _B; }; T size(int i) const { return _B[i]-_A[i]; }; T sizeX() const { return _B[0]-_A[0]; }; T sizeY() const { return _B[1]-_A[1]; };   protected: std::vector<T> _A,_B; };   class Mask { public: //Mask() {}; Mask(int sizex, int sizey, int originX=0, int originY=0):_sx(sizex),_sy(sizey),_ox(originX),_oy(originY){}; Mask(const Box<int>& box):_sx(box.sizeX()),_sy(box.sizeY()),_ox(box.GetA()[0]),_oy(box.GetA()[1]){}; //Mask(const std::vector<int>& A,const std::vector<int>& B){ // Box<int> box(A,B); // Mask(box); // }; ~Mask(){};   protected: int _sx,_sy,_ox,_oy; };

---

Voila.
Donc j'ai une classe Box.
Ensuite je définis une classe Mask. Le constructeur que je souhaite implémenté est commenté.
Le constructeur de la classe Mask a qui on fourni en paramètres deux std::vector<int>, a besoin de méthode de la classe Box pour pouvoir s'initialiser.
D'où mon envie de créer un objet Box intermédiaire et d'appeler ensuite le second constructeur...

Merci à vous

Citation:

---

Envoyé par lg_53

3) Pour ce qui est du swap&copy, vous n'avez pas l'air tous d'accord sur la bonne manière de procéder, mais de toute façon si je travaille avec une structure plus complexe qu'un std::vector, ça semble laborieux à mettre en oeuvre.

---

Si si on est bien d'accord sur la manière de procéder.
L'idiome copy & swap rend le code de l'opérateur d'affectation trivial en utilisant le constructeur par copie et swap qui sont "plus faciles" à implémenter. C'est justement lorsqu'il y a plus qu'un std::vector que ça devient interessant.

Citation:

---

Envoyé par lg_53

4) Pourquoi mettre en protected plutôt qu'en private? C'est un choix personnel. Tout simplement parce que si qqn n'a pas les droits pour modifier la classe mais qu'il souhaite l'améliorer,l'étoffer pour ses propres besoins, et bien il peut faire une classe fllle et a ainsi accès aux attributs librement en lecture et écriture. Là non plus, ce n'est pas ce qui me pose problème.

---

Dans ce cas il faut (généralement) mettre le destructeur en public et virtual.
FAQ C++ - Pourquoi le destructeur d'une classe de base doit être public et virtuel ou protégé et non virtuel ?

Citation:

---

Envoyé par lg_53

Code:

---

1 2 3 4 5

//Mask(const std::vector<int>& A,const std::vector<int>& B){ // Box<int> box(A,B); // Mask(box); // };

---

---

Tout simplement en C++11 :

Code:

---

Mask(std::vector<int> const & a, std::vector<int> const & b) : Mask(Box(a, b)) { }

---

à condition toute fois d'avoir un compilateur assez récent.

Par contre, tu pourrais avoir une méthode static qui fais la même chose:

Code:

---

Mask Mask::create(std::vector<int> const & a, const std::vector<int>& b) {return Mask(Box(a, b));}

---

Citation:

---

Envoyé par Ehonn

std::vector<int> n'a pas de fonction membre swap(). Voir ma proposition au dessus.

---

Perdu :mrgreen: :mrgreen:

std::vector::swap

Autant pour moi, je corrige ça ;)

La classe Box étant templatisée, il faut préciser le type associer lorsqu'on déclare un Box.
Ceci dit donc, voici ma classe réécrite:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Mask { public: //Mask() {}; Mask(int sizex, int sizey, int originX=0, int originY=0):_sx(sizex),_sy(sizey),_ox(originX),_oy(originY){}; Mask(const Box<int>& box):_sx(box.sizeX()),_sy(box.sizeY()),_ox(box.GetA()[0]),_oy(box.GetA()[1]){}; //Mask(const std::vector<int>& A,const std::vector<int>& B):Mask(Box<int>(A,B)){}; // A partir de C++11 Mask(const std::vector<int>& A,const std::vector<int>& B){*this=createMask(A,B);};   Mask createMask(std::vector<int> const & a, const std::vector<int>& b) {return Mask(Box<int>(a, b));};   ~Mask(){};   protected: int _sx,_sy,_ox,_oy; };

---

En C++11 donc, on peut faire un appel à un autre constructeur déjà défini.
Sinon, en réutilisant ta méthode static leternel, on pourrait imaginer écrire le constructeur comme ci-dessus.
L'écriture est correcte? Car j'ai jamais utilisé un "*this=qqch"... Je suppose que ça fait appel au constructeur de copie de la classe, qui ici n'étant pas spécifié est donc celui par défaut qui se contente de recopier les attributs. Corriger moi si je me trompe.

Mes premiers tests ont l'air de fonctionner avec cette façon de faire.

*this = va modifier l'objet précédemment construit, en l'écrabouillant.

Ca n'est pas ça que tu souhaites.

En fait, tu peux être plus extrême.
Pour l'exercice, mets _sx et _sy en constantes. Et nomme les _width et _height, c'est quand même plus clair.
(de même, ox et oy serait left et top).

Dans ces conditions, ton constructeur n'a pas d'autre choix que d'être explicite sur _width et _height.
Du coup, tu n'a pas d'autre choix que de ne pas proposer le constructeur à deux vecteur, mais de contraindre à l'usage de createMask.

Au passage, comme tu es dans Mask, la fonction peut se limiter à create().
Je pensais à une fonction libre.

Les alternatives sont nombreuses:

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

//idiome des créateurs: namespace geom { class Mask { protected: Mask(int width, int height, int originX=0, int originY=0): width(width),height(height),left(originX),top(originY){} public: ~Mask(){};   static Mask create(int width, int height, int originX=0, int originY=0) {return Mask(width, height, originX, originY);} static Mask create(Box<int> const& box) {return Mask(box.sizeX(), box.sizeY(), box.GetA()[0], box.GetA()[1]);} static Mask create(std::vector<int> const & a, std::vector<int> const& b) {return create(Box<int>(a, b));} protected: int width,height; int left,top; }; }//geom::   using geom::Mask;   int main() { Mask a = Mask::create(...); return 0; }

---

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

//idiome des constructeurs nommés: namespace geom { class Mask { protected: Mask(int width, int height, int originX=0, int originY=0): width(width),height(height),left(originX),top(originY){} public: ~Mask(){};   static Mask precise(int width, int height, int originX=0, int originY=0) {return Mask(width, height, originX, originY);} static Mask like(Box<int> const& box) {return Mask(box.sizeX(), box.sizeY(), box.GetA()[0], box.GetA()[1]);} static Mask around(std::vector<int> const & a, std::vector<int> const& b) {return create(Box<int>(a, b));} protected: int width,height; int left,top; }; }//geom::   using geom::Mask;   int main() { Mask a = Mask::precise(12,10,5,5); return 0; }

---

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

//variante fonction libre des créateurs: namespace geom { class Mask { protected: Mask(int width, int height, int originX=0, int originY=0): width(width),height(height),left(originX),top(originY){} public: ~Mask(){};   protected: int width,height; int left,top;   friend Mask create(int width, int height, int originX, int originY); friend Mask create(Box<int> const& box); friend Mask create(std::vector<int> const & a, std::vector<int> const& b; };   inline Mask createMask(int width, int height, int originX=0, int originY=0) { return Mask(width, height, originX, originY); } inline Mask createMask(Box<int> const& box) { return Mask(box.sizeX(), box.sizeY(), box.GetA()[0], box.GetA()[1]); } inline Mask createMask(std::vector<int> const & a, std::vector<int> const& b) { return create(Box<int>(a, b)); }   }//geom::   int main() { geom::Mask a = geom::createMask(...); return 0; }

---

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

//les factories, qui prolonge le précédent. namespace geom { class Mask { protected: Mask(int width, int height, int originX=0, int originY=0): width(width),height(height),left(originX),top(originY){} public: ~Mask(){};   protected: int width,height; int left,top;   friend class MaskFactory; friend class RepetitiveMaskFactory; };   class MaskFactory { public: Mask create(int width, int height, int originX=0, int originY=0) { return Mask(width, height, originX, originY); } Mask create(Box<int> const& box) { return Mask(box.sizeX(), box.sizeY(), box.GetA()[0], box.GetA()[1]); } Mask create(std::vector<int> const & a, std::vector<int> const& b) { return create(Box<int>(a, b)); } };     class RepetitiveMaskFactory { public: const int width, height; public: RepetitiveMaskFactory(int width, int height) : width(width), (height) {}   Mask createAt(int x=0, int y=0) { return Mask(width, height, x, y); } Mask createAt(Mask const& other) { return Mask(width, height, other.left, other.top); } }; }//geom::   using namespace geom; int main() { MaskFactory factory; Mask a = factory.create(50, 50, 8, 12);   RepetitiveMaskFactory creator(12, 18); Mask b = creator.createAt(a); Mask c = creator.createAt(1, 2);   return 0; }

---

Dans les quatre cas, j'ai supprimé le problème de la construction, spécifique, vu que tu as déjà un constructeur direct.

PS aux candidats rouspéteurs: c'est à dessein que j'utilise le même nom pour l'argument du constructeur direct est pour le champ.
Le C++ le permet, et pour constructeur sans corps, c'est simple que jouer avec les préfixes/suffixes.

Merci bien pour se tour d'horizon des possibilités.

Si j'analyse, dans tous les cas, le constructeur de base de la classe est mit en protected.
On contraint alors l'utilisateur à déclarer un objet Mask non pas via une déclaration du type

Code:

---

Mask mon_mask(paramètre...)

---

mais grâce à des méthodes de création d'objet:

Code:

---

1 2	Mask mon_mask=Mask::create(paramètre...) // ou Mask mon_mask2=CreateMask(paramètre...)

---

Pour ce qui est de la méthode des factories (que je ne connaissais pas et qui portent bien leur nom)
on créer donc une classe dont le but est d'instancier un objet Mask. Une usine à Mask littéralement.
Une certaine lourdeur dont je peux me passer ici je pense (autant faire le plus simple possible), mais je garde en tête cet exemple qui m'auras initier aux factories et qui me resserviras un jour j'en suis sûr.

Pour les besoins que j'en ai je vais prendre ta solution proposée en premier (idiome des créateurs).

Merci à vous tous pour vos réactions.

Les factories sont un des design pattern les plus classiques, parce qu'ils permettent de combiner deux niveaux d'informations: un paramétrage général et les cas précis.
Il suffit que le paramétrage général soit conservé dans des champs internes.
C'est ce que j'ai représenté avec RepetitiveMaskFactory.

Salut,

Citation:

---

Envoyé par lg_53

4) Pourquoi mettre en protected plutôt qu'en private? C'est un choix personnel. Tout simplement parce que si qqn n'a pas les droits pour modifier la classe mais qu'il souhaite l'améliorer,l'étoffer pour ses propres besoins, et bien il peut faire une classe fllle et a ainsi accès aux attributs librement en lecture et écriture. Là non plus, ce n'est pas ce qui me pose problème.

---

Voilà une très mauvaise idée...

De manière générale, tu ne devrais avoir que des comportements (AKA fonctions), éventuellement susceptibles d'être redéfinis dans les classes dérivées (AKA fonctions virtuelles) si cela fait sens dans l'accessibilité publique et dans l'accessibilité protégée, et si tu veux vraiment faire les choses de manière, tu essayeras de limiter les accesseurs (AKA "getter") au maximum et tu refuseras avec obstination toute solution à base de mutateurs (AKA setters).

En effet, si tu décides de placer une variable membre dans une accessibilité autre que l'accessibilité privée, tu donnes implicitement le droit à "tout le monde" (même si tu mets une légère restriction au fait que tout le monde se réduit aux classes dérivées en ce qui concerne l'accessibilité protégée) d'aller modifier à sa guise la donnée en question. Cela conduit immanquablement à une perte totale du contrôle que tu peux avoir sur le nombre de fonctions qui iront la modifier, et rend toute tentative d'encapsulation et de programmation par contrat bancale.

Si tu as du mal à comprendre ce que j'explique ou que tu n'arrives pas à comprendre les raisons qui m'incitent à te donner ce conseil, n'hésite pas à me le faire savoir, je développerai volontiers chaque point plus ou moins obscure ;)

Je suis tout à fait d'accord avec toi sur ce point.
Pour moi, une variable est constante ou privée.
Et à priori, même constante, jamais publique.

Certain parleront des static const, mais je n'en vois jamais de vraie utilité.
En général, ce sont des globales déguisées, et je préfère proposer des fonctions statiques qui s'en servent.

Et, lg_53, quand koala01 dit développera, crois-le, car il s'en fera un plaisir... et toi un long moment de lecture :D

Le dévoleppement d'un code bien encapsulé étant une très longue histoire (je vous crois) et n'étant pas le sujet de départ, je vais passé le topic en résolu pour ne pas perdre un lecteur qui passerait par là.

Mon habitude de mettre protected au lieu de private provient certainement d'une expérience que j'ai eu: une fois, j'ai eu besoin d'améliorer une classe développée par quelqu'un d'autre, sans pouvoir la modifier. Sauf que dans cette classe tous les attributs était privés et la classe ne comportait aucun Setter.
Résultat: j'ai dû dupliquer un bout de code beaucoup trop gros pour être normalement dupliqué, jusqu'à ce que l'auteur de cette classe ait changé le private en protected ce qui m'a permis de pouvoir écrire une classe fille. Voici donc pour la petite histoire.

Merci encore à tous.

lg_53

Citation:

---

Envoyé par lg_53

Le dévoleppement d'un code bien encapsulé étant une très longue histoire (je vous crois) et n'étant pas le sujet de départ, je vais passé le topic en résolu pour ne pas perdre un lecteur qui passerait par là.

Mon habitude de mettre protected au lieu de private provient certainement d'une expérience que j'ai eu: une fois, j'ai eu besoin d'améliorer une classe développée par quelqu'un d'autre, sans pouvoir la modifier. Sauf que dans cette classe tous les attributs était privés et la classe ne comportait aucun Setter.
Résultat: j'ai dû dupliquer un bout de code beaucoup trop gros pour être normalement dupliqué, jusqu'à ce que l'auteur de cette classe ait changé le private en protected ce qui m'a permis de pouvoir écrire une classe fille. Voici donc pour la petite histoire.

---

Je comprend parfaitement que tu aies pu avoir une (voir plusieurs) expérience(s) malheureuse(s), mais elle(s) ne devrai(en)t pas te servir de prétexte à la prise de (très) mauvaises habitudes!!!

Il faut savoir que la notion d'encapsulation est régie par une loi appelée loi de Déméter. Cette loi nous dit que, si une class A manipule en interne un objet de type B, l'utilisateur de la classe A ne devrait pas avoir à connaitre le type B pour pouvoir utiliser la classe A.

A partir de là, il faut comprendre que ce ne sont pas les données qui ont de l'importance lorsque l'on décide de créer un agrégat de données (car on peut dire exactement la même chose pour les classes que pour les structures) : ce sont les services qu'il peut nous rendre et les ordres auxquelles il est susceptible de réagir.

On peut à la limite classer les différentes fonctions qui nous permettent de manipuler une classe en deux grandes catégories : les fonctions qui nous permettent d'interroger l'objet afin d'en connaitre l'état à un point de vue donné et celles qui nous permettent d'agir afin de modifier un état particulier.

Les accesseurs entrent bien évidemment dans la première, les mutateurs (setters) entrent quant à eux dans la seconde. Mais, pour ce qui concerne les accesseurs, il n'y a du sens à en proposer un que si l'on peut considérer que le fait d'être en mesure d'accéder à la donnée en question fait partie des services que l'on est en droit d'attendre de la part de la classe.

Par exemple, si tu as une classe Coordonnée qui représente une coordonnée sur un référentiel à deux dimensions, nous sommes en effet en droit de nous attendre à être en mesure de récupérer l'abscisse et l'ordonnée correspondant à une coordonnée particulière.

Mais si tu as une classe Voiture qui dispose (forcément) d'un membre de type ReservoirACarburant, il n'y a absolument aucun sens à fournir un accesseur sur le réservoir en question : on s'attend uniquement à ce que la voiture nous propose un certains nombre de services qui seront sans doute en relation avec la présence du réservoir, mais on ne s'attend absolument pas à être en mesure d'accéder directement au réservoir.

Nous aurons une jauge à carburant nous indiquant la proportion existante entre la quantité actuelle de carburant et la contenance maximale du carburant, nous disposerons peut être de l'affichage d'une évaluation du ombre de kilomètres que l'on peut encore parcourir et nous aurons bien sur une trappe par laquelle nous pourrons rajouter du carburant qui finira forcément dans le réservoir, mais, à moins d'être mécanicien -- et encore -- on n'a absolument aucun besoin de pouvoir accéder directement au réservoir... si tant est qu'il y en a réellement un (comprend: qu'il existe bel et bien une classe Reservoir et que les données relatives au carburant soient bel et bien maintenues par un membre de ce type):D

A partir de là, on peut déjà se dire que, si l'on ne juge pas utile de fournir un accesseur sur un membre donné, il n'y a absolument aucune raison à fournir un mutateur sur cette donnée. Quant à celle pour lesquelles on a décidé de fournir un accesseur, le mutateur est sans doute la plus mauvaise des solutions que nous pourrions envisager.

En effet, l'utilisation d'un mutateur implique que l'on crée un nouvel objet du type (correspondant au type du membre à modifier) dont on a besoin avant de le mettre dans un état "que l'on croit pouvoir être correct" et de fournir cet objet à l'objet que l'on veut modifier.

Le gros problème de cette logique, c'est que tout le contrôle échoit à l'utilisateur : c'est à celui qui va utiliser le setter de s'assurer que l'élément transmis sera dans un état cohérent, alors qu'il n'a peut être qu'un idée trop vague de toutes les conditions qui permettront de dire sans l'ombre d'un doute que "cet état est compatible avec celui auquel on est en droit de s'attendre de la part de notre objet".

Prenons l'exemple d'une d'une classe qui peut être positionnée dans un référentiel à deux dimensions pour te permettre de comprendre. Cette caractéristique est sans doute représentée au niveau des membres de la classe par un membre de type Coordonnée dont je parlais là tantôt. Si cette classe propose une fonction setPosition, c'est à l'utilisateur de s'assurer que la position est correcte, que l'instance de la classe peut effectivement se retrouver à la position indiquée.

Mettons que la position en question corresponde au milieu d'un océan. Les seuls objets réellement susceptibles d'accéder à cette position sont les objets de type "navires" (ou sous marins) et de type "avion" (ou similaires), mais une voiture ne pourra en aucun cas accéder à cette position. Si l'utilisateur doit prendre en compte tous les types d'éléments positionnables et tous les caractéristiques des différents endroits afin de déterminer si un objet bien particulier peut effectivement accéder à une position donnée, je peux te garantir qu'il oubliera systématiquement une ou l'autre combinaison.

Plutôt que de fournir un mutateur sur la position, nous avons donc intérêt à fournir un service "move(diffX, diffY)" ou "moveTo(posX, posY)" qui permettra à l'objet positionnable de s'assurer qu'il peut effectivement atteindre la position à laquelle on lui demande de se rendre. C'est notre objet qui devient responsable de la manière dont son état est modifié.

La différence ne tient pas uniquement au terme utilisé : il ne s'agit pas uniquement d'utiliser moveTo au lieu de setPosition pour que la magie opère. il faut que moveTo mette tout ce qui est nécessaire en oeuvre pour s'assurer que l'objet déplacé puisse effectivement atteindre la position à laquelle on souhaite qu'il se rendre. Mais, comme la vérification sera différente pour un avion, pour un sous-marin et pour un véhicule, si c'est l'objet lui-même qui effectue la vérification, nous pouvons espérer que le développeur de la classe aura pris en compte toutes les conditions qui doivent être remplies ou qui peuvent empêcher un objet de type particulier d'atteindre une position d'un type donné. Et l'utilisateur de la classe n'a plus qu'à s'inquiéter d'interroger l'objet pour savoir s'il est en mesure d'atteindre la position indiquée :D

Si tu as compris ce que j'essayais de te dire, tu comprendra assez facilement le reste :

Les variables membres doivent être placées dans une accessibilités privée pour qu'il n'y ai jamais que les fonctions membres de la classe qui puissent y accéder (que ce soit pour les interroger ou pour les modifier). Les accessibilités publiques et protégées ne devraient contenir que des fonctions membres, qui seront placées dans l'accessibilité publique s'il s'agit de services que "monsieur tout le monde" doit pouvoir utiliser, dans l'accessibilité protégée si ce sont des services auxquels seules les classes dérivées doivent avoir accès.