getteur sur matrice

j'ai une classe qui contient un attribut qui est une matrice .

char tab_gram[20][20];


je voudrais utiliser une methode qui permet de retourner cette matrice afin de pouvoir l'utiliser dans d'autres classes (un getteur en d'autres termes). quel est le corps de ce guetteur?serait t'il mieux d'utiliser des pointeurs?

Déjà, j'en entend qui rale en clamant : utilise "vector !"

Passez ces considération, soit tu fais une structure, soit tu fais un truc super capilotracté en utilisant les pointeur, les cast, etc... mais je dirai pas ce que je pense d'une telle pratique...

Pour la structure, tu peux la faire hérité de vector si tu te veux. Tiens, d'ailleurs je sais pas si c'est "bien" mais tu pourrais faire un :

Code:

---

class Matrix : vector < vector<char> > {};

---

Non il faut pas hériter directement de vecteur (le destructeur n'est pas virtuel) par contre il faut utiliser le typedef de template (possible avec C++0x) sinon en C++03:

Code:

---

1 2 3 4 5 6

template<typename T> struct matrix { typedef vector < vector<T> > type; };

---

Et on peut alors déclarer une matrice:

Code:

---

1 2 3 4 5

int main() { matrix<char>::type ma_matrice; }

---

Si la taille est fixe alors un vector de vector c'est overhead ... Un array C-like fait l'affaire, ou si il veut moins s'embêter (et surtout garder une interface "à la" STL) boost::array, ou ici boost::multi_array.

Définis une classe matrice qui fournira les bons opérateurs d'accès.
Mais ... est-il vraiment nécessaire de rompre l'encapsulation de ta matrice en l'exposant ?

Citation:

---

Déjà, j'en entend qui rale en clamant : utilise "vector !"

---

Non, pourquoi ? Il connait les dimensions de sa matrice.
De plus, le vecteur de vecteurs n'est jamais ma première idée pour les structures rectangulaires...

Salut,

Non seulement je râle en clamant "utilise un vecteur " (:D), mais, en plus, j'aurais tendance à râler en clamant

Citation:

---

QUE FAIS TU DE DEMETER !!!:question::sm:

---

Plus sérieusement, je ne crois vraiment pas qu'il soit de bon ton d'exposer ta matrice "en l'état".

En effet, Si tu as décidé de la placer en accessibilité privée dans ta classe, c'est que tu avais de bonnes raisons de le faire (autrement, tu l'aurait placée en accessibilité publique, ou, à défaut, protégée).

De plus, le fait que ce soit, ici, un tableau "C style" à deux dimension fait vraiment partie de ce que l'on appelle les "détails d'implémentation" de ta classe.

Si, un jour, tu en viens à décider de remplacer (comme beaucoup le suggéreront encore) le tableau C style par... autre chose (boost. multi_array :question:), tu sera bon pour modifier tout le code qui manipule les données récupérées au travers de ce getter :P

En outre, ne sachant absolument pas ce que fait la classe qui utilise ta matrice ni à quelles fin tu veux récupérer cette matrice, nous sommes en droit de nous demander si, quelque part, tu ne t'es pas trompé dans ta conception et s'il ne serait intéressant d'envisager de faire en sorte que ta classe fournisse un service supplémentaire, correspondant à l'usage que tu en aurais si tu récupérait la matrice en l'état.

Si l'idée est, "simplement", de pouvoir accéder aux différentes données contenues dans cette matrice (par exemple, pour pouvoir les envoyer vers un flux quelconque), l'idée générale serait que ta classe fournisse soit un itérateur constant sur le début de la matrice et un itérateur constant sur sa fin (avec le typedef adapté en visibilité publique, cela te permettra d'éviter de devoir modifier le code utilisateur :D), soit de fournir une fonction "valueAt(l, c) " (par exemple) qui renvoie... la valeur se trouvant à la ligne l et à la colon c) de ta matrice.

Enfin, je ne peux m'empêcher de rappeler qu'une matrice de l ligne et c colones peut parfaitement être représentée sous la forme d'un tableau de dimension unique comprenant l*c éléments auxquels nous accédons selon la formule (ligne_recherchée * c) + colonne_recherchée, et que, dans de nombreux cas, cette représentation est suffisante et capable de simplifier énormément la vie du développeur :D

Citation:

---

Envoyé par koala01

Plus sérieusement, je ne crois vraiment pas qu'il soit de bon ton d'exposer ta matrice "en l'état".

---

Je trouve que tu t'avances beaucoup... On ne sait absolument rien d'autre sur son code; mis à part qu'elle veux retourner une matrice ?

Dans tous les cas, faire un tableau dimension 1, c'est un peu galère pour pas grand chose je trouve. Ça résous le problème du passage en argument mais pas le retour... Je prèfère encore le mettre dans une structure basique.

Citation:

---

Envoyé par Lavock

Je trouve que tu t'avances beaucoup... On ne sait absolument rien d'autre sur son code; mis à part qu'elle veux retourner une matrice ?

---

Justement, non, je ne m'avance pas...

Le respect de la loi demeter, qui est quelque part mis à mal lorsque tu veux renvoyer un membre "complexe" au travers d'un getter est, pour moi, une priorité...

Nous ne savons, effectivement rien de la classe ni de son utilisation, mais ce que nous pouvons estimer, c'est que le fait que les données soient représentées sous la forme d'un tableau carré à deux dimensions n'est en réalité qu'un détail d'implémentation.

Dés lors, comme je l'ai indiqué, il me semble largement plus intéressant de cacher ce fait en fournissant des comportements qui permettent d'accéder au donnée de ce tableau plutôt qu'au tableau lui-même, et qui permettent de décider finalement à n'importe quel moment de modifier ce détail d'implémentation sans devoir modifier le code par ailleurs.

Citation:

---

Dans tous les cas, faire un tableau dimension 1, c'est un peu galère pour pas grand chose je trouve. Ça résous le problème du passage en argument mais pas le retour... Je prèfère encore le mettre dans une structure basique.

---

Cela n'a pas grand chose de galère, et encore moins si, comme je le suggère, nous cachons le détail d'implémentation que cela représente...

La formule permettant d'accéder à un élément se trouvant à la ligne l et à la colonne c est connue et facile à mettre en oeuvre (c'est d'ailleurs de cette manière que les tableaux 2D de taille connue sont représentés en C ;)) et nous évite de devoir jouer avec des std::vector de std::vector (ce que je me refuse à faire chaque fois que possible) ou de devoir commencer à créer une classe "ligne" cachant le détail d'implémentation qu'elle manipule un... std::vector d'élément et une classe matrice manipulant un... std::vector<ligne> et devant cacher ce détail d'impélmentation.

En effet, cette manière de concevoir les choses pose le problème que l'ajout d'une ligne dans la matrice n'est absolument pas "naturel" à effectuer :P ;)