Discussion :

[gabgab]

Bonjour à tous,

Voilà je vous écris car j'ai un petit soucis de conception...

Je veux créer un plateau de jeu générique qui pourrait s'adapter à différents jeux. Celui-ci est représenté par un vecteur de type template T : vector<T>.

Petit souci : comment tester si une case de plateau est occupée ou non ? La seule idée qui me vient en tête c'est d'au lieu d'utiliser un vecteur d'objet je ferais mieux d'utiliser un vecteur de pointeur sur ces objets : vector<T*>, comme ca je pourrais tester vector<T*>.at(i)==0 ce qui signifique que la case est vide...

Mais bon je trouve ça un peu moche d'utiliser les pointeurs (ai-je tort ?) donc voilà je voulais savoir si quelqu'un voyait une autre alternative à mon problème...

Merci d'avance

[Iradrille]

Hello,

Ça dépend entièrement de la façon dont tu représentes les données.
Ça peut aller d'un vector d'enum où l'index dans le vector détermine la position

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
enum Piece {
    Aucune,
    Piece1,
    Piece2
};
 
std::vector<Piece> plateau;
// tester si une pièce est dans la case (4,5)
bool pieceIn4_5 = plateau[4*largeur+5] != Aucune;

A un vector de Piece contenant leur position

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
struct Piece {
    Position position;
    // ...
};
std::vector<Piece> pieces;
// tester si une pièce est dans la case (4,5)
using std::begin;
using std::end;
bool pieceIn4_5 = std::find_if(begin(pieces), end(pieces), [](const Piece& p)->bool {
    return p.position == Position(4,5);
}) != end(pieces);

Il est aussi possible d'avoir plusieurs représentations des données en simultané. Il faut juste bien faire attention à les garder synchronisées.

Réfléchi bien à la (ou les) façon de représenter les données la plus efficace (et simple d'utilisation).

Mais bon je trouve ça un peu moche d'utiliser les pointeurs (ai-je tort ?) donc voilà je voulais savoir si quelqu'un voyait une autre alternative à mon problème...

Avec ce genre de représentation tu sera obligé d'utiliser des pointeurs, mais ce n'est pas dérangeant.

[gabgab]

Tout d'abord merci pour ton aide.

Le truc qui me dérange dans ta réponse, c'est que j'ai l'impression que tu ne prends pas en compte les templates. En effet en suivant ton exemple j'aurais un plateau de type Piece uniquement.
Après une solution possible serait de déclarer un type pièce template...

[Ehonn]

Bonjour

Tu peux regarder du coté de boost::optional, std::optional (refusé pour C++14) ou équivalent.

[Iradrille]

Le truc qui me dérange dans ta réponse, c'est que j'ai l'impression que tu ne prends pas en compte les templates. En effet en suivant ton exemple j'aurais un plateau de type Piece uniquement.

Je donnais juste des exemples avec un type concret car c'est plus facile à relire, mais il est tout à fait possible d'avoir des templates.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template <class T>
class Plateau {
public:
    typedef T piece_type;
 
    // ...
private:
    // au choix, en fonction de la représentation des données
    // tu peux aussi avoir quelque chose de complètement différent.
    std::vector<piece_type*> m_pieces;
    std::vector<std::optional<piece_type>> m_pieces;
    std::vector<piece_type> m_pieces;
    std::vector<std::reference_wrapper<piece_type>> m_pieces;
};

Le problème n'est pas l'utilisation de templates, mais de savoir comment représenter les données pour que ce soit simple et rapide à utiliser.

[Bousk]

il n'y a rien de moche à utiliser des pointeurs et il ne faut pas avoir peur des pointeurs.

[Ehonn]

Il n'y a pas de raison d'utiliser des pointeurs bruts ici. Selon la sémantique de T (et de part le statut de std::optional), j'hésiterai entre un std::vector<???::optional<T>> et un std::vector<std::unique_ptr<T>>.

Si std::optional ou équivalent est disponible alors, j'utiliserai :
- std::vector<???::optional<T>> si T a une sémantique de copie.
- std::vector<std::unique_ptr<T>> si T a une sémantique d'entité.

L'utilisation basique reste la même : ???::optional et std::unique_ptr peuvent être utilisés tous les deux comme booléen et on peut accéder à la valeur par déréférencement.

[koala01]

Salut,

La première question à se poser est surtout de savoir quelle sera la nature de l'objet qui prendra place sur le plateau.

Je m'explique : imaginons que tu crées un échiquier. Les pièces que tu placeras sur ton plateau seront sans doute des objets présentant des comportements polymorphes, parce que la "pièce" peut représenter un pion, une tour, un cavalier,un fou, une dame ou un roi et que chaque pièce spécifique aura des comportements spécifiques.

Tu te trouves donc avec des classes qui ont, très clairement, sémantique d'entité pour lesquelles ils sera difficile d'utiliser un identifiant unique (à cause du nombre d'éléments qu'il faudrait identifier de manière unique).

Tu n'auras donc pas le choix : il faudra que les cases de ton plateau manipulent un pointeur vers les différentes pièces. (*)

Pour d'autres jeux (puissance 4, otello, scrabble, ...), les éléments qui prennent place sur le plateau peuvent parfaitement être représentés par des classes ayant sémantique d'entité :

Si je prend le cas de otello, les jetons ont une face blanche et une face noire, mais il n'y a strictement aucun besoin de partir sur une hiérarchie de classes pour les pions : les pions de ces jeux (si tant est qu'on utilise une classe et non une simple énumération ) se satisfait parfaitement d'une sémantique de valeur.

A ce moment là, tu peux parfaitement envisager de créer une simple énumération dans laquelle tu places les différentes valeurs possibles et à laquelle tu rajoutes une valeur qui représente... l'absence de pion / couleur / lettre (biffer la mention inutile ).

Si tu veux, vraiment, avoir un plateau générique, il faut prendre, ad minima, des deux possibilités en compte, ce qui ferait sans doute ressembler ton plateau à quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
/* !!! C++11 inside !!! */
struct EntityTag{};
struct ValueTag{};
 
struct OthelloTag{
    using gameTag = ValueTag;
};
struct ChessTag{
    using gameTag = EntityTag;
};
template <typename BoardType>
class Board{
    public:
        using boardTag = BoardType::gameTag;
        template <typename T = boardTag,
                        typename = typename
                        <std::enable_if<std::is_same<T,ValueTag>::value>::type>
        void foo(T const & /* , ... */ ){
 
        }
        template <typename T = boardTag,
                        typename = typename
                        <std::enable_if<std::is_same<T,EntityTag>::value>::type>
        void foo(T const & /* , ... */ ){
 
        }
       /* ... */
}

Ou, si tu ne disposes pas de C++11, il faudra partir sur une spécialisation de ta classes, sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct EntityTag{};
struct ValueTag{};
template <typename Tag, typename PieceBaseType>
class Board;
template<
class Board<ValueTag, void>{
    public:
    /* ici, on travaille avec des éléments qui ont sémantique de valeur */
    /* ... */
};
template<typename PieceBaseType>
class Board<EntityTag, PieceBaseType>{
    public:
    /* ici, on travaille avec des éléments qui ont sémantique d'entité */
    /* ... */
};

(ce ne sont que deux possibilités parmi d'autres, je n'ai pas réfléchi très longtemps au problème )

(*) Lorsque tu dois manipuler des éléments qui ont sémantique d'entité, tu peux toujours envisager le recours à l'idiôme de l'objet nul (Nul Object idiomen anglais ).

En effet, ce n'est pas parce que ton plateau manipule des pointeurs en interne qu'il doit obligatoirement renvoyer un pointeur : Si tu peux définir un type qui représente "l'absence de pièce", tu es sauvé

Pour faire simle, l'idée est d'intégrer, dans ta hiérarchie de classes, une classe qui répond "false" (ou une valeur connue pour être invalide) à toutes les questions que l'on peut lui poser :

• mayHaveChildren false
• hasChildren false
• color colorNone
• coordinate Corrdinate(0,0) (ou la valeur qui indique que la coordonnée n'existe pas)
• canMove false
• ...

Ainsi, dans chaque classe qui manipule en interne un pointeur vers la classe de base de ta hiérarchie de classes, tu peux rajouter un membre de ce type "qui n'est pas un élément valide", et décider de renvoyer ce membre là à chaque fois que tu veux signifier le fait que "il n'y a rien à cet endroit là"

C'est, à peu de chose près, ce qui se fait avec les itérateurs (les fonctions end() essentiellement )