Discussion :

[mangeclous]

Bonjour,

Je souhaiterai utiliser le type variant< stack<int>,queue<int> > et définir les fonctions add et remove qui ajoute et retire un élément dans ces listes. Comment faire ceci? je pensais que variant étaient une union améliorée.
Peut-être que j'ai fait un mauvais choix.


Merci pour votre aide,
mangeclous


PS: je n'ai pris que le cas avec 2 piles mais j'en aurai d'autres à ajouter c'est pour ça que j'aimerai mettre mes actions sur les piles en commun

[Nogane]

Bonjour,

Pour faire une fonction manipulant un variant, le mieux est de passer par un visiteur:

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
class add : public boost::static_visitor<>
{
  int val;
public:
   add(int v):val(v){}
 
   void operator()(T &container) const
   {
       container.push(val);
   }
};
 
class remove : public boost::static_visitor<int>
{
public:
    int operator()(T &container) const
    {
        return container.pop();
    }
};
 
variant< stack<int>,queue<int> > myVar = stack<int>();
boost::apply_visitor( add(3), myVar);
boost::apply_visitor( remove(3), myVar);

Cela dit, je ne suis pas sur de l’intérêt de faire un variant dans ce cas.
J'aurais plutôt créé une class contenant une liste, avec un booleen pour me dire si je suis en mode FIFO ou en mode LIFO.

Par exemple:

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
class MyList
{
  list<int> list_;
  enum Mode
  {
    FIFO,
    LIFO
  } mode;
public:
  MyList():mode(LIFO){}
 
  void add(int val)
  {
    if(mode == FIFO)
      list_.push_back(val)
    else
      list_.push_front(val)
  }
};

[Emmanuel Deloget]

Je dirais qu'il y a de fortes, très fortes chances que tu n'ai pas besoin d'un type variant. Le type variant permet de stocker des données de type différent dans une variable au type indéfini. Visiblement, ce que tu souhaites faire, c'est une sorte d'adapteur qui permet d'unifier l'interface des classes dont tu as besoin (en soi, ce n'est pas nécessairement une bonne idée, mais c'est un autre débat). Je ferais quelque chose dans ce goût là :

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
 
template <class Stack> class stack_adapter;
 
template <class T, class Alloc>
class stack_adapter<std::queue<T,Alloc> >
{
public:
  void push(const T& elem) { ... }
  void pop() { ... }
  // renvoie le prochain élément disponible, 
  // ou throw si aucun élément dans la pile
  const T& next() const { ... }
  T& next() { ... }
  // nombre d'éléments
  std::size_t size() const { ... }
};

Maintenant, si une classe a une interface spécifique (par exemple stack<> vs. queue<>) c'est qu'il y a une raison. Vouloir harmoniser les interfaces de classes dont le but est différent au niveau sémantique n'est probablement pas la meilleure chose à faire.

[mangeclous]

(en soi, ce n'est pas nécessairement une bonne idée, mais c'est un autre débat)

Débattons! j'aimerai bien que tu m'expliques la bonne approche.

L'utilisateur va choisir un critère de sortie de liste: fifo, lifo, hifo et lofo(highest et lowest), plus une autre que je vais devoir définir à la main.
J'aimerai traiter cette liste "uniformément"

thanks

[mangeclous]

Maintenant, si une classe a une interface spécifique (par exemple stack<> vs. queue<>) c'est qu'il y a une raison. Vouloir harmoniser les interfaces de classes dont le but est différent au niveau sémantique n'est probablement pas la meilleure chose à faire.

en fait j'ai juste besoin de savoir comment les éléments s'entassent et "se détassent", donc je pensais unifier le tout. Pê que la solution de Nogane est la plus simple, donc la meilleure pour moi.

[koala01]

Débattons! j'aimerai bien que tu m'expliques la bonne approche.

L'utilisateur va choisir un critère de sortie de liste: fifo, lifo, hifo et lofo(highest et lowest), plus une autre que je vais devoir définir à la main.
J'aimerai traiter cette liste "uniformément"

thanks

Il faut bien comprendre que FIFO, LIFO, HIFO et LOFO font partie de ce que l'on peut appeler les "concepts de base" qui ne sont d'ailleurs pas forcément limités à la programmation (et qui le sont donc encore moins au C++ )

Ces concepts vont déterminer la manière dont les éléments sont gérés à l'ajout et à la suppression. Mais cela signifie qu'ils vont aussi déterminer les termes qui seront utilisés pour l'ajout et la suppression (plus la présence éventuelle d'autres possibilités de gestion) :

Avec une pile (LIFO), on va empiler et dépiler, alors que dans une file (FIFO), on va ajouter et retirer, qu'une liste nous permettra d'ajouter au début et à la fin, d'insérer, de retirer à n'importe quelle position et de trier et que HIFO/LOFO ne permettent que d'insérer et de retirer (car on n'a pas à savoir à la base quelle sera la position finale de l'éléement qu'on ajoute )

Cela implique que chaque concept n'est utilisable que dans une situation particulière bien précise : un restaurant qui utiliserait le concept LIFO pour son stock ou une ménagère qui utiliserait le concept FIFO pour ses assiettes coureraient à leur perte !

Si l'on souhaite "rationnaliser" les interfaces de ces différents concepts, il faut en réalité de préférence partir sur une solution basée sur ce que l'on appelle les politique (pour éviter que l'utilisateur n'essaye de manipuler les objets de manière indue), mais les différentes collections gérées ne devraient pas l'être de manière totalement indsitinctes : dans le meilleur des cas, les piles seront gérées avec les piles, les files avec les files, et ainsi de suite, mais le concept mis en oeuvre est discriminant, et on ne devrait donc pas permettre de mettre des piles avec des files ou avec des listes

[Emmanuel Deloget]

Débattons! j'aimerai bien que tu m'expliques la bonne approche.

Je n'ai pas sous-entendu que j'avais une meilleure approche à proposer, pour la simple et bonne raison que je n'ai pas fait le design de ton application, et qu'il faudrait que tu me le communique complètement (ou presque) pour que je puisse te donner un avis qui ne serait, au mieux, que consultatif.

L'utilisateur va choisir un critère de sortie de liste: fifo, lifo, hifo et lofo(highest et lowest), plus une autre que je vais devoir définir à la main.
J'aimerai traiter cette liste "uniformément"

abstract factory + adapteurs dérivant d'une classe de base ; la factory permet de choisir le type réel en fonction d'un critère choisi par l'utilisateur, et renvoie un objet dont le type statique propose les services dont tu as besoin et dont le type dynamique repose sur la technologie choisie par l'utilisateur.

Vouloir passer par des templates pour faire ça va avoir un impact significatif sur ton code, qui va d'une part se retrouver templatisé là où tu t'y attends le moins, et d'autre part va te forcer à écrire quantité de choix basés sur les distinctions de types afin de pouvoir spécialiser tes algorithmes. L'approche que j'ai décrit plus haut devrait permettre de limiter une partie des problèmes, mais pas tous.

De mon point de vue, mais il ne vaut peut-être pas grand chose, la seule solution viable du point de vue design est celle que je décrit ci-dessus (abstract factory + adapteurs dérivants d'une classe de base).