Discussion :

[Jack_serious]

Bonjour.

Apres pas mal de recherche, je suis venu poser la question:

Comment faire pour iterer une stack ?
Je parle ici de la classe stack de la STL.

Comment peut on recuperer un iterator sur cette stack, afin de pouvoir l'afficher en entier ?

[Laurent Gomila]

Faut lire la doc :

Stack does not allow iteration through its elements

This restriction is the only reason for stack to exist at all. Note that any Front Insertion Sequence or Back Insertion Sequence can be used as a stack; in the case of vector, for example, the stack operations are the member functions back, push_back, and pop_back. The only reason to use the container adaptor stack instead is to make it clear that you are performing only stack operations, and no other operations.

[Jack_serious]

Tu m'etonne que j'arrivais pas a trouver.

De la doc j'en ai lu un paquet mais je n'avais pas trouve celle la...

Bon... J'ai plus qu'a changer le conteneur.

Merci pour ta reponse et bonne journee!

[Laurent Gomila]

Il y a plein de bonne doc ici
http://c.developpez.com/faq/cpp/?pag...ERALITE_cppdoc

[Jack_serious]

Bookmarked.

Thanks

[koala01]

Salut,

Quelque part, il est normal qu'il ne soit pas possible d'itérer sur une "stack"...

la "stack", c'est une "pile"... Tu ne peux donc accéder qu'à l'élément qui se trouve "en haut de la pile"...

Toute tentative de prendre un élément se trouvant ailleurs se soldera... par la "chute" des éléments qui se trouvent au dessus de l'élément auquel tu essaye d'accéder

C'est une implémentation concrete d'un système FILO(First In, Last Out: le premier entré est le dernier à sortir)

[Médinoc]

Généralement, on dit LIFO et non FILO...

Et aussi, je trouve bizarre que la stack ne donne pas accès au nième élément en partant du haut de la pile.
Cela empêche d'implémenter une vraie machine virtuelle à pile en utilisant stack (typiquement, un processeur à pile met des variables locales sur la pile pour y accéder plus tard, qu'il ait des registres ou non).

[Jack_serious]

Exact.

Donc pour faire une pile, et pouvoir quand meme l'iterer, il faut utiliser la classe list, qu'on peut utiliser comme une stack.

On utilise my_list->push_front(), my_list->pop_front().

Et on peut l'iterer sans probleme:

Code :

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

1
2
3
4
5
6
7
8
9
 
list<MyClass>::iterator  it;
 
it = my_list.begin();
while (it != my_list.end())
{
  // do something here;
  ++it;
}

[koala01]

LIFO...FILO... Finalement, c'est choux vert et vert choux, non

Ceci dit, le but meme d'une pile n'est pas de permettre un acces itératif (on a les listes pour cela) mais bel et bien de permettre la sauvegarde d'une série (dont on ignore a priori le nombre) d'éléments, et leur récupération selon le principe LIFO...

C'est à dire: t'en rajoute trois, t'en traite 1, tu en rajoute 5, t'en traite 2, ...

Le traitement occasionne la suppression de l'élément et permet de passer à celui qui a été introduit juste avant...

Voici à peu pres comment ca fonctionne



Un peu (enfin, meme carrément ) à l'image de ce qui se fait au niveau du processeur lors de l'appel de fonctions: tu ne peu pas récupérer les valeurs de la fonction "arrière grand mere" avant d'avoir fini de traiter la fonction "enfant" et la fonction "mere"...

[Médinoc]

Un peu (enfin, meme carrément ) à l'image de ce qui se fait au niveau du processeur lors de l'appel de fonctions: tu ne peu pas récupérer les valeurs de la fonction "arrière grand mere" avant d'avoir fini de traiter la fonction "enfant" et la fonction "mere"...

Oui, mais dans une même fonction, tu peux accéder à diverses variables locales, toutes placées sur la pile pour un x86, et ce dans n'importe quel ordre...

Une pile où l'on n'a accès qu'au dernier élément n'est bonne que pour évaluer des expressions...

[koala01]

Oui, mais dans une même fonction, tu peux accéder à diverses variables locales, toutes placées sur la pile pour un x86, et ce dans n'importe quel ordre...

Une pile où l'on n'a accès qu'au dernier élément n'est bonne que pour évaluer des expressions...

Sauf que, quand tu y réfléchis bien, tu ne dispose que des valeurs propres à la fonction gérée... un peu comme si toutes ces valeur étaient mises dans une "mega structure"...

Quand tu crées une pile "manuellement", que tu crées deux structures distinctes:
une pour les données en elles-meme

Code :

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

1
2
3
4
5
6
7
8
 
struct Data
{
    int machin;
    bool truc;
    string bidule;
    ...
}

et une pour la pile en elle-meme, qui contient la structure des données

Code :

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

1
2
3
4
5
6
 
struct Pile
{
    Data Donnees;
    Pile *Precedent;
}

ou que tu décides de tout mettre dans une seule structure:

Code :

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

1
2
3
4
5
6
7
8
9
 
struct Pile2
{
    int machin;
    bool truc;
    string bidule;
    ...
    Pile *Precedent;
};

Rien ne t'empeche d'accéder à Pile->Donnees->machin ou à Pile2->machin...

Et tu as meme un acces aléatoire aux différentes données d'un meme noeud (tu ne dois pas *forcément* gérer machin avant de pouvoir gérer truc...)

Mais il n'empeche que tu ne peux accéder qu'au noeud de la pile qui se trouve actuellement "au sommet"...

Une pile, par définition, ce n'est pas itératif (sinon, ca devient une liste...)
[EDIT] Ceci dit, tu n'as pas tout à fait tord: une pile n'est, effectivement, intéressante que dans une optique proche de l'évaluation d'expressions...