$course$/QCM de NSI/Terminale/Listes, piles, files Structures de données linéaires : listes chaînées, piles
(LIFO) et files (FIFO). Opérations de base, complexité,
implémentations possibles, applications classiques (parcours,
parenthésage, parcours en largeur, etc.).

]]> Listes, piles, files — Q01 : Définition d'une pile Quel est le principe d'une pile (stack) ?

]]> Les piles sont fondamentales en informatique : pile
d'appels de fonctions, gestion d'historique (Ctrl+Z),
analyse syntaxique de parenthèses, parcours en
profondeur d'un graphe.

]]> 1.0 0.0 0 true true abc Premier entré, premier sorti (FIFO)

]]> Erreur : c'est le principe d'une file (queue),
pas d'une pile. Confusion classique entre les deux.

]]> Accès aléatoire à n'importe quel élément

]]> Erreur : ce serait un tableau classique. Une pile
impose un accès uniquement par le sommet.

]]> Tri automatique des éléments

]]> Erreur : aucun tri. Les éléments sont stockés dans
leur ordre d'arrivée, accessible uniquement par
le sommet.

]]> Dernier entré, premier sorti (LIFO)

]]> Bonne réponse : LIFO (Last In, First Out). On
ajoute (push) et on retire (pop) toujours par le
sommet. C'est le comportement d'une pile
d'assiettes : on prend toujours celle du haut.

]]> Listes, piles, files — Q02 : Définition d'une file Quel est le principe d'une file (queue) ?

]]> Les files sont utilisées pour : tâches en attente
(imprimante, ordonnanceur), parcours en largeur d'un graphe,
buffers de communication, et tout système où l'on
veut respecter l'ordre d'arrivée.

]]> 1.0 0.0 0 true true abc Élimination automatique des doublons

]]> Erreur : aucune dédoublonnage automatique.

]]> Premier entré, premier sorti (FIFO)

]]> Bonne réponse : FIFO (First In, First Out). On
ajoute en queue (enfilement) et on retire en tête
(défilement). C'est le comportement d'une file
d'attente au supermarché.

]]> Dernier entré, premier sorti (LIFO)

]]> Erreur : c'est le principe d'une pile, pas
d'une file.

]]> Accès direct au milieu de la structure

]]> Erreur : la file impose l'accès uniquement aux
extrémités.

]]> Listes, piles, files — Q03 : Opérations sur une pile Quelles sont les deux opérations principales d'une
pile ?

]]> Toutes ces opérations s'effectuent en temps constant
O(1) avec une bonne implémentation. C'est l'avantage
principal des piles et files par rapport aux
structures plus complexes.

]]> 1.0 0.0 0 true true abc get et set

]]> Erreur : ce sont des opérations d'accès indexé,
plutôt sur un tableau ou un dictionnaire.

]]> add et remove

]]> Erreur : ces noms sont génériques. Les noms
standard sur une pile sont plus spécifiques.

]]> push (empiler) et pop (dépiler)

]]> Bonne réponse : push(x) ajoute x au sommet ;
pop() retire et renvoie l'élément du sommet. On
a aussi souvent peek() ou top() (consulter
sans retirer) et is_empty() (tester la vacuité).

]]> enqueue et dequeue

]]> Erreur : ce sont les opérations d'une file,
pas d'une pile.

]]> Listes, piles, files — Q04 : Opérations sur une file Quelles sont les opérations principales d'une file ?

]]> Les noms varient selon les langages : push /
shift en JavaScript, append / popleft avec
collections.deque en Python, etc. Le concept reste
le même.

]]> 1.0 0.0 0 true true abc push et pop

]]> Erreur : ce sont les opérations d'une pile,
pas d'une file.

]]> min et max

]]> Erreur : ce sont des opérations d'agrégation, pas
de file.

]]> enqueue (enfiler) et dequeue (défiler)

]]> Bonne réponse : enqueue(x) ajoute x à la queue ;
dequeue() retire et renvoie l'élément en tête.
Comme pour la pile, ces opérations sont en O(1).

]]> sort et reverse

]]> Erreur : opérations sur les listes, pas sur les
files.

]]> Listes, piles, files — Q05 : Application classique des piles Pour vérifier qu'une expression contient des
parenthèses bien équilibrées (par exemple
((a + b) * c)), quelle structure est la plus adaptée ?

]]> Cet exemple illustre bien le LIFO : la dernière
parenthèse ouverte est celle qui doit être fermée en
premier. L'algorithme s'étend aux crochets [],
accolades {}, balises HTML, etc.

]]> 1.0 0.0 0 true true abc Une pile (LIFO)

]]> Bonne réponse : on empile les parenthèses
ouvrantes ; à chaque parenthèse fermante, on
dépile et on vérifie la correspondance. À la fin,
la pile doit être vide. C'est l'algorithme
standard.

]]> Un tableau trié

]]> Erreur : aucun rapport avec un tri. C'est l'ordre
d'apparition qui compte, ce qui est une pile.

]]> Une file (FIFO)

]]> Erreur : la file ne convient pas. Pour
l'équilibrage, on a besoin d'accéder à la
parenthèse ouvrante la plus récente, ce qui est
du LIFO.

]]> Un dictionnaire

]]> Erreur : le dictionnaire n'est pas adapté à un
ordre temporel. La pile est la bonne structure.

]]> Listes, piles, files — Q06 : Application classique des files Pour gérer une file d'impression (les documents
arrivés en premier sont imprimés en premier), quelle
structure utiliser ?

]]> Variantes possibles : files de priorité (où
l'ordre dépend d'une priorité, pas seulement
d'arrivée), implémentées par des tas (heaps) plutôt
que des files simples.

]]> 1.0 0.0 0 true true abc Une pile

]]> Erreur : avec une pile, le dernier document arrivé
serait imprimé en premier, ce qui est injuste.

]]> Une liste triée par taille

]]> Erreur : trier par taille fausserait l'ordre
d'arrivée. Sauf si on veut une politique
spécifique (le plus petit d'abord), mais ce n'est
pas FIFO.

]]> Un dictionnaire

]]> Erreur : pas de notion d'ordre temporel naturelle
dans un dictionnaire.

]]> Une file

]]> Bonne réponse : la file (FIFO) garantit que
l'ordre d'arrivée est respecté. C'est exactement
l'usage typique : ordonnanceur du système
d'exploitation, file d'impression, tampon
réseau.

]]> Listes, piles, files — Q07 : Pile en Python En Python, une manière simple d'implémenter une pile
utilise :

]]> Pour une pile « propre », on préférera implémenter une
classe Pile avec méthodes empiler, depiler,
est_vide, etc. Cela cache la liste sous-jacente et
empêche les usages aberrants (accès indexé direct).

]]> 1.0 0.0 0 true true abc Une liste avec append() pour empiler et pop() pour dépiler

]]> Bonne réponse : lst.append(x) ajoute en fin
(sommet) et lst.pop() retire la fin (sommet),
tous deux en O(1) amorti. Simple et efficace.

]]> Un dictionnaire

]]> Erreur : le dictionnaire n'a pas de notion d'ordre
en place pour cet usage.

]]> Un simple entier

]]> Un entier est une valeur
unique : il ne peut pas
contenir une suite
d'éléments empilés
successivement.

]]> Une chaîne de caractères

]]> Erreur : les chaînes sont immuables en Python.
Empiler créerait une nouvelle chaîne à chaque
opération, c'est inefficace.

]]> Listes, piles, files — Q08 : File en Python efficace Pour implémenter une file efficace en Python, quelle
structure de la bibliothèque standard utilise-t-on ?

]]> Bonne pratique : from collections import deque ;
f = deque() ; f.append(x) ; f.popleft(). C'est aussi
ce qu'utilisent les algorithmes parcours en largeur sur des graphes.

]]> 1.0 0.0 0 true true abc collections.deque (file double-ended) avec append() et popleft(), toutes deux en O(1)

]]> Bonne réponse : deque est la structure adaptée.
Elle permet l'ajout et la suppression aux deux
bouts en temps constant.

]]> tuple

]]> Erreur : un tuple est immuable. On ne peut pas y
ajouter d'éléments.

]]> list, en utilisant append() et pop(0)

]]> Erreur : pop(0) est en O(n) car il faut
décaler tous les éléments. C'est inefficace pour
de grandes files.

]]> set (ensemble)

]]> Erreur : un ensemble n'a pas d'ordre. Inadapté à
une file.

]]> Listes, piles, files — Q09 : Pile d'appels Quel rôle joue la pile d'appels (call stack) lors
de l'exécution d'un programme ?

]]> C'est précisément la pile d'appels qui sature en cas
de récursion infinie, provoquant le célèbre
RecursionError ou stack overflow. Sa taille est
typiquement limitée à quelques dizaines de milliers
d'appels.

]]> 1.0 0.0 0 true true abc Stocker les fichiers ouverts

]]> Erreur : les fichiers sont gérés par le système
d'exploitation, pas par la pile d'appels.

]]> Stocker les données d'une base de données

]]> Une base de données est
stockée sur le disque
dans des structures
dédiées, sans rapport
avec la pile d'appels
gérée par
l'interpréteur.

]]> Compter les variables globales

]]> Erreur : aucun rapport. La pile d'appels gère les
contextes locaux.

]]> Empiler le contexte de chaque appel de fonction (paramètres, variables locales, adresse de retour) et le dépiler à la fin de la fonction

]]> Bonne réponse : c'est exactement le rôle d'une
pile au sens LIFO. Quand une fonction A appelle B,
le contexte de A reste empilé sous celui de B,
jusqu'à ce que B se termine et qu'on dépile pour
revenir à A.

]]> Listes, piles, files — Q10 : Liste chaînée Qu'est-ce qu'une liste chaînée ?

]]> Variantes : listes simplement chaînées (un seul
pointeur next), doublement chaînées (next et
previous), circulaires (le dernier pointe vers le
premier). Chaque variante a ses cas d'usage.

]]> 1.0 0.0 0 true true abc Une liste reliée à une base de données

]]> Erreur : aucun rapport avec une base de données.

]]> Une liste qui ne peut pas être modifiée

]]> Erreur : ce serait une liste immuable. Une liste
chaînée peut tout à fait être modifiée.

]]> Une liste chiffrée

]]> Erreur : « chaînée » et « chiffrée » sont des
mots différents. Aucun rapport avec la
cryptographie.

]]> Une liste où chaque élément contient sa valeur et une référence vers l'élément suivant

]]> Bonne réponse : contrairement à un tableau (mémoire
contiguë), une liste chaînée est composée de
maillons qui se référencent. Ajouter ou supprimer
en tête se fait en O(1), mais l'accès indexé
coûte O(n).

]]> Listes, piles, files — Q11 : Complexité des opérations sur une pile Quelle est la complexité des opérations push et pop
sur une pile, pour une bonne implémentation ?

]]> Avec une liste Python, append et pop() (sans
argument) sont en O(1) amorti. Avec une liste
chaînée et un pointeur sur le sommet, c'est aussi
O(1). Pas de surprise.

]]> 1.0 0.0 0 true true abc O(n) pour les deux

]]> Erreur : c'est trop coûteux. Les piles sont
réputées efficaces parce que ces opérations sont
en temps constant.

]]> O(\log n) pour les deux

]]> Erreur : pas de raison logarithmique. C'est un
accès direct.

]]> O(1) pour les deux

]]> Bonne réponse : push et pop agissent toujours
au sommet, donc en temps constant. C'est ce qui
rend les piles si utiles dans les algorithmes
comme la conversion infixe → postfixe ou le parcours en profondeur.

]]> O(n²) pour les deux

]]> Erreur : excessif.

]]> Listes, piles, files — Q12 : Accès indexé dans une liste chaînée Quelle est la complexité d'accéder au k-ième élément
d'une liste chaînée simplement chaînée ?

]]> C'est le compromis fondamental : une liste chaînée
offre des insertions/suppressions efficaces (O(1)
en tête, O(n) ailleurs), mais un accès indexé lent.
Pour un accès rapide, utiliser un tableau.

]]> 1.0 0.0 0 true true abc O(k) (linéaire)

]]> Bonne réponse : il faut suivre les pointeurs un
par un depuis la tête. Pour atteindre l'élément
k, il faut k étapes.

]]> O(\log k)

]]> Erreur : pas de division par deux possible. C'est
plutôt linéaire.

]]> O(1)

]]> Erreur : les listes chaînées n'offrent pas
d'accès indexé en temps constant, contrairement
aux tableaux. Il faut parcourir.

]]> O(k²)

]]> Erreur : excessif.

]]> Listes, piles, files — Q13 : Évaluation d'une expression postfixée L'évaluation d'une expression en notation postfixée
(par exemple 2 3 + 4 *) utilise :

]]> Cette technique est utilisée dans les calculatrices
RPN (HP, par exemple) et dans certaines machines
virtuelles (la JVM). Elle évite la gestion explicite
des parenthèses.

]]> 1.0 0.0 0 true true abc Une file

]]> Erreur : la file ne fonctionne pas pour ce cas. La
notation postfixée demande d'accéder aux deux
derniers opérandes, ce qui est typiquement LIFO.

]]> Un dictionnaire

]]> Le dictionnaire associe
des clés à des valeurs ;
il ne reflète pas l'ordre
temporel d'arrivée des
opérandes nécessaire à
l'évaluation d'une
expression postfixée.

]]> Un arbre binaire

]]> Erreur : on peut représenter une expression par
un arbre, mais l'évaluation postfixée utilise une
pile.

]]> Une pile : on empile les nombres et, à chaque opérateur, on dépile les deux derniers, on calcule, et on rempile le résultat

]]> Bonne réponse : pour 2 3 + 4 , on empile 2,
puis 3 ; on rencontre +, on dépile 3 et 2,
on calcule 5, on empile 5 ; on empile 4 ;
on rencontre , on dépile 4 et 5, on calcule
20. Résultat : 20.

]]> Listes, piles, files — Q14 : Parcours en largeur et parcours en profondeur Pour un parcours en largeur d'un graphe ou
d'un arbre, quelle structure utilise-t-on ?

]]> Mémo : pile = profondeur ; file = largeur.
C'est l'application algorithmique la plus
classique de ces deux structures.

]]> 1.0 0.0 0 true true abc Une file

]]> Bonne réponse : on enfile les voisins à explorer
; en défilant à chaque étape, on visite d'abord
tous les voisins du niveau actuel avant de passer
au suivant. C'est exactement le parcours en
largeur.

]]> Un dictionnaire

]]> Erreur : pas de structure d'ordre dans un
dictionnaire (sauf en Python 3.7+, mais ce
n'est pas l'intention ici).

]]> Une liste triée

]]> Erreur : aucun tri n'est requis pour parcours en largeur.

]]> Une pile

]]> Erreur : la pile correspond au parcours en
profondeur. Pour la largeur, c'est
différent.

]]> Listes, piles, files — Q15 : Distinction entre interface et implémentation « Pile » et « file » sont des interfaces abstraites.
Cela signifie que :

]]> C'est l'idée des types abstraits de données
(TAD) : on spécifie ce que la structure doit
faire, pas comment. Une pile peut être implémentée
de plusieurs façons, l'utilisateur du TAD ne s'en
soucie pas.

]]> 1.0 0.0 0 true true abc Elles sont écrites en assembleur

]]> Erreur : aucun rapport avec le langage.

]]> Elles définissent un comportement (LIFO ou FIFO) sans imposer la structure interne (tableau, liste chaînée, etc.)

]]> Bonne réponse : on peut implémenter une pile avec
une liste Python, une liste chaînée, un tableau,
etc. Tant que les opérations respectent LIFO,
c'est une pile. Cette abstraction est essentielle
en programmation modulaire.

]]> Elles sont obsolètes

]]> Erreur : elles sont au contraire fondamentales et
omniprésentes.

]]> Elles ne peuvent pas être implémentées en Python

]]> Erreur : Python permet bien sûr d'implémenter ces
structures.

]]> Listes, piles, files — Q16 : Pile vide Que faut-il faire avant de tenter un pop() sur une
pile ?

]]> Bonne pratique : encapsuler la pile dans une classe
qui lève une exception explicite (PileVideError)
plutôt que d'exposer l'erreur Python brute. Cela
rend le code utilisateur plus clair.

]]> 1.0 0.0 0 true true abc Recalculer la longueur

]]> Erreur : pas de calcul à faire avant un pop.

]]> Vérifier qu'elle n'est pas vide (par exemple avec is_empty())

]]> Bonne réponse : un pop sur pile vide provoque
en général une erreur (IndexError en Python). Il
faut toujours vérifier d'abord, ou capturer
l'exception.

]]> Toujours appeler peek() d'abord

]]> Erreur : peek() consulte mais ne protège pas
d'un pop sur une pile vide.

]]> Multiplier la taille par deux

]]> Erreur : aucun rapport. Aucune opération de
redimensionnement n'est nécessaire avant un pop.

]]> Listes, piles, files — Q17 : Liste chaînée vs tableau Quel est l'avantage principal d'une liste chaînée
sur un tableau dynamique ?

]]> Compromis classique : tableau pour l'accès indexé
rapide ; liste chaînée pour les insertions/suppressions
fréquentes en début ou milieu (avec un pointeur sur
l'emplacement).

]]> 1.0 0.0 0 true true abc L'accès indexé est plus rapide

]]> Erreur : c'est l'inverse. Le tableau a un accès
O(1), la liste chaînée O(n).

]]> L'insertion et la suppression en tête se font en temps constant, sans avoir à décaler d'autres éléments

]]> Bonne réponse : c'est l'avantage clé. Avec un
tableau, insérer en tête demande de décaler tous
les éléments. Avec une liste chaînée, on
modifie juste un pointeur.

]]> Elle utilise moins de mémoire

]]> Erreur : c'est l'inverse, en général. Une liste
chaînée stocke un pointeur supplémentaire par
élément, ce qui consomme plus de mémoire.

]]> Elle est intrinsèquement triée

]]> Erreur : aucun tri automatique.

]]> Listes, piles, files — Q18 : Implémentation orientée objet d'une pile En Python, dans une classe Pile minimale, quelles
méthodes définit-on typiquement ?

]]> Encapsulation : la liste sous-jacente est privée
(self._tab ou self.__tab). L'utilisateur ne
manipule que les méthodes de la pile, pas la liste.
C'est ce qui distingue une pile abstraite d'un
tableau libre.

]]> 1.0 0.0 0 true true abc get, set indexés

]]> Erreur : ce serait un tableau, pas une pile.

]]> add, remove, find, sort

]]> Erreur : ces méthodes ne correspondent pas à
l'API d'une pile. Une pile n'offre pas de find
ou sort.

]]> Une seule méthode do()

]]> Erreur : trop minimaliste. Une pile expose
plusieurs opérations distinctes.

]]> empiler(x), depiler(), sommet() (ou peek), est_vide()

]]> Bonne réponse : ces quatre méthodes constituent
l'API minimale d'une pile. Souvent, on ajoute
taille() ou __len__() pour des raisons
pratiques.

]]> Listes, piles, files — Q19 : Détection de parenthèses déséquilibrées L'expression (()) est-elle bien parenthésée ? Et
(() ?

]]> Règle algorithmique : une expression est bien
parenthésée si et seulement si la pile est vide à la
fin, ET qu'aucune fermante n'apparaît sur une pile
vide pendant le parcours.

]]> 1.0 0.0 0 true true abc Toutes deux sont bien parenthésées

]]> Erreur : (() ne ferme pas la première
parenthèse. Donc déséquilibrée.

]]> La parité du nombre de caractères suffit à juger

]]> Erreur : ()( est de longueur paire mais
déséquilibré. La parité ne suffit pas.

]]> (()) est correcte ; (() est incorrecte (la première parenthèse n'est jamais fermée)

]]> Bonne réponse : avec une pile, on empile chaque
(, on dépile à chaque ). À la fin de la
deuxième chaîne, la pile contient encore une
parenthèse non fermée, donc déséquilibrée.

]]> Toutes deux sont incorrectes

]]> Erreur : (()) est parfaitement équilibrée :
deux parenthèses ouvrantes, deux fermantes, dans
le bon ordre.

]]> Listes, piles, files — Q20 : Analyse d'un code de pile Que renvoie le code Python suivant ?

`
pile = []
for x in [1, 2, 3, 4]:
pile.append(x)
print(pile.pop())
`

]]> Comportement standard LIFO : dernier entré, premier
sorti. Si on continuait à pop() plusieurs fois, on
obtiendrait 4, 3, 2, 1 dans l'ordre.

]]> 1.0 0.0 0 true true abc 0

]]> Erreur : aucun rapport avec 0.

]]> La liste entière [1, 2, 3]

]]> Erreur : pop() ne retourne qu'un seul élément.

]]> 1

]]> Erreur : c'est l'élément de bas de pile (le
premier empilé). Mais pop() retire le sommet
(le dernier empilé).

]]> 4

]]> Bonne réponse : on a empilé 1, 2, 3, 4. Le
sommet est 4. pop() retire et renvoie 4.

]]> Listes, piles, files — Q21 : Pourquoi pas list.pop(0) pour une file Pourquoi list.pop(0) est-il inefficace pour
implémenter une file en Python ?

]]> C'est un piège classique en Python. deque (de
double-ended queue) est l'outil adapté pour des
files efficaces, avec append à droite et
popleft à gauche, tous deux en O(1).

]]> 1.0 0.0 0 true true abc Parce que les listes Python ne sont pas mutables

]]> Erreur : les listes sont mutables.

]]> Parce qu'il faut décaler tous les autres éléments d'un cran vers la gauche, ce qui est en O(n)

]]> Bonne réponse : les listes Python sont des
tableaux dynamiques contigus en mémoire. Retirer
le premier élément force à recopier tous les
autres. Pour une file efficace, utiliser
collections.deque (deux pointeurs internes,
O(1) aux deux bouts).

]]> Parce que ça lève toujours une erreur

]]> Erreur : pop(0) fonctionne sur une liste non
vide. Le problème est la performance, pas la
correction.

]]> Parce que pop ne peut pas prendre d'argument

]]> Erreur : pop(i) accepte un argument optionnel.

]]> Listes, piles, files — Q22 : Tampon circulaire Un tampon circulaire (ring buffer) est :

]]> Le tampon circulaire est très efficace : pas
d'allocation dynamique, mémoire prévisible. Mais sa
taille étant fixe, il faut gérer le cas où il est
plein (écraser les anciens, ou refuser le nouveau).

]]> 1.0 0.0 0 true true abc Un dictionnaire trié

]]> Un dictionnaire associe
des clés à des valeurs et
n'a pas de notion de
tampon ni de circularité.
Le tampon circulaire est
quant à lui une file de
taille fixe utilisée pour
des flux continus.

]]> Une liste chaînée fermée

]]> Erreur : c'est plutôt une liste circulaire, pas un
tampon circulaire.

]]> Une file implémentée sur un tableau de taille fixe, où l'on revient au début quand on dépasse la fin

]]> Bonne réponse : très utilisé pour des buffers
temps-réel (audio, vidéo, journaux d'événements).
Comme la taille est fixe, on évite les
allocations dynamiques, et la « circularité »
permet d'utiliser tout l'espace disponible.

]]> Une pile de taille variable

]]> Un tampon circulaire
n'est pas une pile : il
implémente une file (au
sens FIFO) sur un
tableau de taille fixe,
comme expliqué dans la
bonne réponse.

]]> Listes, piles, files — Q23 : Récursivité et pile Toute fonction récursive peut être convertie en une
version itérative utilisant explicitement :

]]> Cette technique de dérécursivation est utile
quand la profondeur de récursion dépasse la limite
Python (souvent 1000). On remplace les appels par
des push/pop sur une pile explicite, et on contrôle
ainsi la mémoire utilisée.

]]> 1.0 0.0 0 true true abc Une file

]]> Erreur : la récursivité a une nature LIFO (l'appel
le plus profond est traité en premier). C'est
donc une pile.

]]> Un dictionnaire

]]> Erreur : un dictionnaire ne préserve pas l'ordre
d'appels. La structure adaptée est une pile.

]]> Une pile, qui simule la pile d'appels gérée implicitement par le langage

]]> Bonne réponse : c'est précisément ce que fait le
processeur en interne. En remplaçant les appels
récursifs par des opérations sur une pile
explicite, on transforme une fonction récursive
en boucle. Cela peut éviter les dépassements de
pile.

]]> Un arbre

]]> Erreur : un arbre est une donnée, pas un
mécanisme d'exécution.

]]> Listes, piles, files — Q24 : File de priorité Une file de priorité (priority queue) diffère d'une
file FIFO classique en ce que :

]]> Files de priorité utilisées dans : Dijkstra (plus
courts chemins), algorithme A*, ordonnancement par
priorité, simulation d'événements discrets. En
Python : module heapq.

]]> 1.0 0.0 0 true true abc Elle ne stocke que les nombres

]]> Erreur : on peut y stocker n'importe quel type
d'élément, à condition d'avoir un critère de
priorité.

]]> Aucune différence

]]> Erreur : la différence est essentielle.

]]> Elle est plus rapide que la file ordinaire

]]> Erreur : elle est généralement plus lente
(O(\log n) vs O(1)). L'avantage est
fonctionnel, pas la rapidité.

]]> L'élément retiré est celui qui a la priorité la plus élevée, pas forcément le plus ancien

]]> Bonne réponse : par exemple, dans un hôpital, on
traite d'abord les cas les plus urgents, pas
ceux arrivés en premier. Implémentation typique :
un tas binaire (heap), avec opérations en
O(\log n).

]]> Listes, piles, files — Q25 : Choisir la bonne structure On souhaite gérer l'historique des actions d'un éditeur
de texte, avec une fonction « annuler » (Ctrl+Z). Quelle
structure est la plus adaptée ?

]]> Petit défi : implémenter Ctrl+Z et Ctrl+Y. Astuce
classique : deux piles. Quand on annule, on dépile de
la pile « historique » et on empile dans la pile
« refait ». Quand on refait, c'est l'inverse.

]]> 1.0 0.0 0 true true abc Une liste triée

]]> Erreur : pas de tri à faire ; l'ordre est déjà
donné par l'arrivée.

]]> Un dictionnaire

]]> Erreur : pas de notion temporelle adaptée.

]]> Une pile

]]> Bonne réponse : à chaque action, on l'empile.
Ctrl+Z dépile et annule la dernière. C'est le cas
d'usage typique des piles. Pour le « refaire »
(Ctrl+Y), on utilise une deuxième pile.

]]> Une file

]]> Erreur : la file annulerait la première action,
pas la dernière. Or « annuler » concerne la plus
récente.

]]> Listes, piles, files — Q26 : Maillon d'une liste chaînée On souhaite implémenter une liste simplement chaînée
en Python. Quelle classe représente un maillon
correctement ?

]]> Pour parcourir la liste chaînée, on commence par la
tête et on suit les pointeurs suivant jusqu'à
atteindre None. La classe Maillon est l'élément
atomique ; la classe ListeChainee (ou directement
une variable « tête ») gère la collection.

]]> 1.0 0.0 0 true true abc `
class Maillon:
def __init__(self, valeur):
self.valeur = valeur
`

]]> Erreur : il manque l'attribut suivant. Sans
lui, le maillon ne peut pas pointer vers le
suivant et la « chaîne » est cassée. Ce serait
juste un conteneur de valeur, pas un maillon.

]]> `
class Maillon:
def __init__(self, valeur, suivant=None):
self.valeur = valeur
self.suivant = suivant
`

]]> Bonne réponse : un maillon contient sa propre
valeur et une référence vers le maillon suivant
(ou None si c'est le dernier). C'est la
définition canonique. La construction d'une
liste chaînée se fait ensuite en chaînant
plusieurs maillons via leur attribut suivant.

]]> `
def maillon(valeur):
return [valeur]
`

]]> Erreur : on retourne ici une liste Python avec
un seul élément, ce qui n'est pas un maillon.
Pour chaîner plusieurs valeurs, il faudrait
imbriquer des listes, ce qui est lourd et peu
clair par rapport à une vraie classe.

]]> `
class Maillon:
def __init__(self, valeur, precedent, suivant):
self.valeur = valeur
self.precedent = precedent
self.suivant = suivant
`

]]> Erreur : on a ici un maillon doublement
chaîné (avec un pointeur vers le précédent et
un vers le suivant). C'est utile pour certaines
structures, mais la question portait sur une
liste simplement chaînée.

]]> Listes, piles, files — Q27 : Parcours en profondeur avec pile explicite Pour effectuer un parcours en profondeur d'un arbre
ou d'un graphe sans utiliser la récursivité, quel
algorithme et quelle structure utilise-t-on ?

]]> Mémoire récurrente :
- Pile + parcours = parcours en profondeur.
- File + parcours = parcours en largeur.
Cette dualité s'observe sur les arbres comme sur
les graphes, et illustre la puissance des
structures linéaires LIFO/FIFO en algorithmique.

]]> 1.0 0.0 0 true true abc On utilise une pile : on empile le sommet de
départ, puis on répète : dépiler un sommet, le
marquer comme visité, et empiler ses voisins
non visités. La pile reproduit l'ordre LIFO de
la récursion

]]> Bonne réponse : la pile explicite simule
exactement ce que ferait la récursion via la
pile d'appels du langage. C'est un cas concret
de dérécursivation. Avantage : on contrôle la
mémoire et on évite les RecursionError sur
les graphes profonds.

]]> On utilise un dictionnaire pour stocker les
sommets visités

]]> Réponse partielle : un dictionnaire (ou un
ensemble) sert effectivement à mémoriser les
sommets déjà visités, mais ce n'est pas la
structure qui dirige le parcours. C'est la
pile (ou la file) qui décide de l'ordre de
visite.

]]> On utilise une file : on enfile le sommet
de départ et on défile à chaque étape

]]> Erreur : avec une file (FIFO), on obtient un
parcours en largeur, pas en profondeur.
Le parcours en profondeur explore d'abord
les descendants avant les frères, ce qui est
un comportement LIFO.

]]> On trie d'abord les sommets puis on les parcourt
dans l'ordre

]]> Erreur : on parle ici d'un parcours qui
respecte la structure du graphe ou de l'arbre,
pas d'un parcours par valeur croissante. Trier
n'a pas de sens dans ce contexte.

]]> Listes, piles, files — Q28 : Annuler et refaire avec deux piles On veut implémenter une fonctionnalité « annuler »
(Ctrl+Z) et « refaire » (Ctrl+Y) dans un éditeur.
Quelle structure utiliser ?

]]> Variante avancée : pour gérer un historique
arborescent (où chaque action peut produire une
branche), il faut utiliser un arbre, pas
seulement deux piles. C'est le modèle utilisé par
certains éditeurs avancés (vim, Emacs en mode
undo-tree).

]]> 1.0 0.0 0 true true abc Un dictionnaire indexé par l'instant de l'action

]]> Solution surdimensionnée : un dictionnaire
permet d'aller à n'importe quel instant, ce
qui n'est pas demandé pour Ctrl+Z/Ctrl+Y. Les
deux opérations agissent toujours sur la
dernière action ou la dernière action
annulée, ce qui correspond à des piles.

]]> Une file pour l'historique, une pile pour le
refaire

]]> Erreur : une file annulerait l'action la plus
ancienne (FIFO), alors qu'on veut annuler la
plus récente (LIFO). Il faut donc une pile
pour l'historique, pas une file.

]]> Deux piles : une pile « historique » qui contient
les actions déjà effectuées, et une pile
« refaire » qui contient les actions annulées.
Annuler = dépiler de l'historique, empiler dans
refaire ; refaire = dépiler de refaire,
empiler dans l'historique. Toute nouvelle
action vide la pile « refaire »

]]> Bonne réponse : c'est le schéma standard des
éditeurs de texte. Les deux piles évoluent
symétriquement, sauf au moment d'une nouvelle
action, qui rend impossible de « refaire » les
actions annulées précédemment (c'est le
comportement attendu : on ne peut pas refaire
ce qui n'existe plus dans la branche
d'historique courante).

]]> Une seule pile suffit

]]> Erreur : avec une seule pile, on peut annuler
mais on perd définitivement les actions
annulées. Pour pouvoir les refaire, il
faut les conserver quelque part : c'est le
rôle de la deuxième pile.

]]>