Fonction qui renvoie un int (*)[15]

Salut, à tous.

Je suis en train de faire un jeu, et dans la classe qui représente la carte, j'ai un tableau à deux dimensions, contenant les détails du terrain.

Le problème, c'est que j'en ai besoin avec d'autres classes pour gerer les collisions, et donc j'utilisais le mot clé friend, pour rendre plusieurs classes amies.

Mais maintenant, j'ai envie de rendre ça plus "propre", et donc, je veux faire une fonction qui renvoie ce tableau, mais je ne sais as quoi spécifier comme retour, car quand je mets :

Code:

---

1 2 3 4

int Carte::getMap() { return m_carte; }

---

Je reçois cette erreur : "Cannot convert int(*)[15] to int". J'ai essayé plein d'autres trucs qui n'ont pas marché.

Merci de m'aider :D

si tu fais int mafonction() oui tu retournes un int.
si ton tableau est de la forme myTab[][], c'est donc un int **

essaies comme ca....

"Cannot convert int(*)[15] to int** in return"

Peux tu me donner la declaration de m_carte dans la classe Carte

Dans le .h je mets ça en private :

int m_carte[1000][15];

Citation:

---

Envoyé par bogoss91

Code:

---

1 2 3 4

int Carte::getMap() { return m_carte; }

---

---

Je te conseil ceci, test et dit moi si ca marche bien, et pas seulement a la compilation:

Code:

---

1 2 3 4

int Carte::getMap() { return (int **)m_carte; }

---

int** et int[][] ne sont pas compatibles, au contraire de int* et int[]. Ici il faut renvoyer un int[1000][15].

mais ceci est equivalent : char *argv[] et char **argv, je pensais que par extension....
le prototype de fonction devient : int[1000][25] get... ? c'est un peu statique comme truc

J'ai essayé de faire ça :

Code:

---

1 2 3 4

int[1000][15] Carte::getMap() { return m_carte; }

---

Et ça n'a pas marché : "Expected unqualified id before '[' token"

Apres test en effet avec un cast (int**) on obtient un access vio.
Laurent ? Il n'est pas possible de definir un type de retour comme int[20][30] mafonction()....?

Code:

---

1 2 3 4

int mafonction()[1000][15] {   }

---

Avec un typedef c'est mieux :

Code:

---

1 2 3 4 5 6

typedef int MonType[1000][15];   MonType mafonction() {   }

---

Citation:

---

typedef int MonType[1000][15];

MonType mafonction() { }

---

sauf que même avec un typedef, on ne peut pas retourner des tableaux C, ce ne sont pas des objets assignables.

Mais on peut retourner un tableau dans une structure, ou utiliser boost::array<>.

... Je retourne me coucher ... :oops:

m_carte est bien un pointeur de tableau? on ne peut pas le balader?

Ce qui veut dire, s'il veut pouvoir retourner un tableau, il doit utiliser un int**?

Donc moi là je dois faire comment? :?

Ce que tu peux faire c'est de modifier ta declaration de tableau en int **
A ce moment la dans le constructeur de ta classe tu lui alloues l'espace mémoire requis.
Allocation de memoire dynamique

Apres ta methode pourra retourner un int ** et tu n'aura plus ce problème.

Dans ce cas autant gérer un int[1000*15] et renvoyer un int*. Ca évitera la double allocation dynamique et tous ses problèmes.

Pour préciser ce qu'a dit Laurent, tu peux gérer un tableau à une dimension comme un tableau à deux dimensions.

Code:

---

1 2 3 4

int at(int i, int j) { return tab[i*1000 + j*15]; }

---

A moins que ce soit l'inverse, je ne me rappelle plus.

Salut,

si le tableau est de l'ordre de int tab[1000][15], la formule est

Code:

---

1 2 3 4

int LaClasse::fonction(int ligne, int col) { return tab[ligne*15+col]; }

---

De manière générale, c'est element=numero_ligne*MAX_COLONE+numero_colone ;)

Oulà, ça devient compliqué tout ça :lol: De toute façon pour l'instant ça urge pas, donc je vais liasser ça comme ça, et si ça me gêne plus tard je changerai.

Ben, ca n'a rien de vraiment compliqué...

C'est juste logique, et on va donc réexpliquer;)

Quand tu déclare un tableau tab[linge][colone], c'est un tableau qui fait linge*colone éléments

Quand tu passe à la première colone de la deuxième ligne, c'est, normalement que tu a déjà parcouru la première ligne, et tu te trouve donc au "colone"ieme+1 élément...

Comme les index commencent à 0 en C et en C++, la première ligne et la première colone ont l'index 0, et donc le premier élément que l'on trouve à la ligne 1 (la deuxième) est en fait l'élément qui se trouve à l'index ... colone ;)

On *pourrait* envisager d'inverser la place de l'index des ligne et des colones dans le calcul, mais, l'idée de base est d'utiliser la même convention que ce qui se fait pour la gestion des matrices en mathématiques: M(ligne, colone)

Si donc tu applique le calcul numéro_ligne * nombre_element_par_colone + numéro_colone, la priorité de la multiplication sur l'addition fait que le calcul tombe juste parce que cela revient à (calculer numéro_ligne* nombre_element_par_colone) + numéro_colone :D

Tu vois, y a rien de tellement compliqué à tout cela ;)

Je vais faire mon ch...eur ;)

Mais conceptuellement, y a un problême quand même....

D'un coté tu mets le membre privé (donc le but est d'en cacher l'implémentation), et d'un autre côté tu "fixes" et publies l'implémentation en renvoyant un tableau...
Si c'est pour faire ca... autant mettre le membre public ! Enfin bon....

Sinon, peut être que ca te suffirai amplement (en tout cas, c'est ce que j'aurai fait):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class Carte { // implémentation privée... int m_carte[1000][15]; inline void check(int x, int y) { assert(x>=0 && x<1000); assert(y>=0 && y<15); }     public:   inline int getAt(int x, int y) const { check(x,y); return m_carte[x][y]; }   inline void setAt(int x, int y, int value) { check(x,y); m_carte[x][y] = value; } };

---

Pas forcément...

Avoir un "getter" et un "setter" permet, justement, d'avoir une abstraction supplémentaire...

Un tableau à deux dimensions peut être représenté par plusieurs choses:

• type tab[ligne*colone]
• type mat[ligne][colone]
• vector<type> tab(ligne*colone)
• vector< vector<type> > mat
• ...

Tu peux, à n'importe quel moment, décider de modifier la manière dont les (ligne*colone) éléments sont représenté en mémoire, et ce pour des raisons qui ne tiennent peut être qu'à toi

Si tu fournis le membre avec une visibilité publique, tu accepte implicitement que tout le monde utilise directement le membre en question...

Si tu décide de modifier la manière dont le membre est représenté en mémoire, non seulement, tout ton code devra être revu pour l'adapter à la nouvelle représentation, mais, si ton code a pour but de fournir une bibliothèque, tout le code des utilisateurs de la bibliothèque devra être modifié... Avec les problèmes de compatibilité entre les versions que cela implique.

Par contre, si tu fournis le membre avec une visibilité privée, et que tu fournis des méthodes qui vont bien (getters et setters, mais aussi, pourquoi pas, la possibilité de modifier les dimensions de ta matrice), dans l'ensemble du code qui sera présenté, il n'y aura qu'un nombre restreint d'endroits à modifier pour adapter à la nouvelle représentation en mémoire du membre... avec un avantage certain au niveau de la compatibilité...

Cela n'a pas l'air énorme, mais n'avoir qu'à modifier deux ou trois fonctions (ou à peine plus si tu envisage des fonctions push_front/push_back, insert, remove, clear etc) plutôt que de devoir parcourir l'ensemble du code pour s'assurer que tu modifies tous les endroits où tu accède au membre public, ca facilite énormément la tache de mise à jour ;)

Sauf qu'en l'occurrence le "getter" possède un type de retour tel que changer l'implémentation n'est pas possible. Je souhaite bien du courage à qui veut implémenter par exemple un "getter" retournant par exemple un int** qui marche aussi bien si l'implémentation derrière est un int** et si c'est un vector<int>...

Dans ce genre de cas, je préfère :
- Soit fournir dans la classe des fonctions d'accès à une case du tableau uniquement
- Soit ajouter un niveau d'abstraction supplémentaire, et avoir un type genre Matrice, l'utiliser dans l'implémentation comme l'interface de ma classe, et si je veux changer des choses, c'est ce type que je modifie.

Citation:

---

Envoyé par JolyLoic

Sauf qu'en l'occurrence le "getter" possède un type de retour tel que changer l'implémentation n'est pas possible. Je souhaite bien du courage à qui veut implémenter par exemple un "getter" retournant par exemple un int** qui marche aussi bien si l'implémentation derrière est un int** et si c'est un vector<int>...

Dans ce genre de cas, je préfère :
- Soit fournir dans la classe des fonctions d'accès à une case du tableau uniquement
- Soit ajouter un niveau d'abstraction supplémentaire, et avoir un type genre Matrice, l'utiliser dans l'implémentation comme l'interface de ma classe, et si je veux changer des choses, c'est ce type que je modifie.

---

De fait... j'aurais du préciser que cela impliquerait sans doute un niveau d'abstraction supplémentaire, mais il n'empêche que le fait d'avoir "getter", "setter" et une encapsulation de données correcte reste quand même de nature à améliorer la compatibilité entre les versions ;)

Citation:

---

Envoyé par JolyLoic

Dans ce genre de cas, je préfère :
- Soit fournir dans la classe des fonctions d'accès à une case du tableau uniquement
- Soit ajouter un niveau d'abstraction supplémentaire, et avoir un type genre Matrice, l'utiliser dans l'implémentation comme l'interface de ma classe, et si je veux changer des choses, c'est ce type que je modifie.

---

Exactement (voir d'ailleurs le code que je proposais)...

Koala a du lire mon message en diagonale ! :D
Ce que je disais c'est "si c'est pour avoir un getter qui renvoit un tableau de int** alors ca veut dire que l'implémentation est fortement liée à un int** !" et dans l'exemple donné, autant passer le membre public... tout changement d'implémentation modifiant forcément le getter, et, par voie de conséquence, les utilisateurs de la classe.

Des getter/setter sur une valeur permettent de faire abstraction de comment ces valeurs sont organisées en mémoire.

De plus un getter qui renvoit un int** veut dire que derrière, c'est obligatoirement un int** qu'on a. Pourquoi ? parceque sinon, il devrait aussi y avoir un mécanisme pour indiquer à l'objet d'origine qu'on a modifié les valeurs dans le tableau !

La fonction renverrait un const int** .... par contre.... ;)

Salut,

A mon avis un accesseur c'est bien souvent un code smell.
Pas seulement parce que ça bousille l'encapsulation mais plutôt parce que ça inverse le sens du flux d'exécution et du coup ça inverse aussi les dépendances entre objets.

Par exemple ici on obtient une dépendance depuis d'autres objets vers Carte, uniquement pour pouvoir faire un 'get' et donc pour obtenir des données.
L'orienté objet est quand même plus axé traitements que données (c'est un des courants en tous cas), idéalement il faut s'efforcer de transformer ce genre de dépendance pour les inverser : que l'objet Carte avertisse les autres objets qui en ont besoin lors d'une modification (pattern observateur, etc..).

Ca a l'air anecdotique et on se dit "holala la grosse artillerie qu'est l'observateur c'est quand même plus simple de faire un get", néanmoins plus on systématise cette inversion de contrôle et plus on voit les avantages se dégager dont la plus importante est je trouve la facilité de mise en place de proxies (vas-y faire un proxy sur un accesseur qui renvoit un int** pour décrire la carte).
Ca permet aussi de "lisser" les dépendances (et le flux d'exécution) en les mettant toutes dans le même sens : on peut les suivre linéairement sans avoir besoin de faire des aller-retours tout le temps (typiquement ce que fait un accesseur).
Pour donner une image ça transforme un diagramme de séquence très en hauteur en un tout en largeur.

Ca demande de se forcer un peu au début, mais ça vaut franchement le coup. Au final je trouve ça beaucoup plus simple, plus modulaire, plus souple, etc.. :)

MAT.

Citation:

---

Envoyé par Mat007

Salut,

A mon avis un accesseur c'est bien souvent un code smell.
Pas seulement parce que ça bousille l'encapsulation mais plutôt parce que ça inverse le sens du flux d'exécution et du coup ça inverse aussi les dépendances entre objets.

Par exemple ici on obtient une dépendance depuis d'autres objets vers Carte, uniquement pour pouvoir faire un 'get' et donc pour obtenir des données.
L'orienté objet est quand même plus axé traitements que données (c'est un des courants en tous cas), idéalement il faut s'efforcer de transformer ce genre de dépendance pour les inverser : que l'objet Carte avertisse les autres objets qui en ont besoin lors d'une modification (pattern observateur, etc..).

Ca a l'air anecdotique et on se dit "holala la grosse artillerie qu'est l'observateur c'est quand même plus simple de faire un get", néanmoins plus on systématise cette inversion de contrôle et plus on voit les avantages se dégager dont la plus importante est je trouve la facilité de mise en place de proxies (vas-y faire un proxy sur un accesseur qui renvoit un int** pour décrire la carte).
Ca permet aussi de "lisser" les dépendances (et le flux d'exécution) en les mettant toutes dans le même sens : on peut les suivre linéairement sans avoir besoin de faire des aller-retours tout le temps (typiquement ce que fait un accesseur).
Pour donner une image ça transforme un diagramme de séquence très en hauteur en un tout en largeur.

Ca demande de se forcer un peu au début, mais ça vaut franchement le coup. Au final je trouve ça beaucoup plus simple, plus modulaire, plus souple, etc.. :)

MAT.

---

8O Et comment on fait ça? :P

En pratique ici, avec quelque chose comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class MapObserver { public: virtual void Notify( int** map ) = 0; };   class Map { public: explicit Map( MapObserver& observer ) : observer_( observer ) {}   private: void Update() { observer_.Notify( map_ ); }   private: MapObserver& observer_; int** map_; };

---

Il manque sans doute des const mais ça donne l'idée.
Ensuite c'est donc Map qui est chargé de prévenir l'observateur en cas de modification via la méthode helper Update.

Les avantages :
. lorsque la carte change (on change de niveau par exemple) c'est Map qui déclenche la mise à jour et non du code extérieur, on a donc une meilleure encapsulation et on ne risque pas d'oublier de faire ce qu'il faut où il faut
. si on rajoute une nouvelle raison pour changer la carte (typiquement on peut changer de carte en cours de jeu et non plus uniquement à l'initialisation au début) on a très peu de modifications à apporter au reste du code : tout le mécanisme existe déjà
. si on souhaite qu'en fonction des joueurs la carte ne soit pas la même (typiquement ce qu'on appelle un 'fog of war', c'est à dire que certaines parties sont cachées à certains joueurs) on peut facilement (et de manière transparente pour tout le reste du système) intercaler un objet (appelé proxy) entre Map et le(s) 'vrai(s)' observateur(s) qui va implémenter aussi MapObserver et qui va filtrer la carte au passage (on peut aussi y parvenir avec un accesseur mais c'est souvent moins facile à mettre en place)
. on peut facilement transformer un appel Notify( liste< Element > ) en 'n' appels Notify( Element ), ça permet souvent de simplifier un tas de trucs en centralisant les boucles sur les éléments (faites une seule fois dans Update et non dans le Notify de chaque observateur), et ça encapsule les conteneurs utilisés
. etc..

Bizarrement l'observateur ne fait pas partie des patterns décrit dans la FAQ alors que c'est sans doute un des trois plus importants (avec le proxy et la factory), il y a une description sur wikipedia mais qui n'est pas forcément fantastique...

MAT.

Tu peux retourner un int(*)[15] (c'est-à-dire un pointeur vers un tableau de 15 entiers), comme proposé par l'erreur de ton compilateur.

Code:

---

1 2 3 4

int (*Carte::getMap())[15] { return m_carte; }

---