j'ai une question con...je peux ?
voici
quel est intérêt de la stack lorsque les container on déjà des fonctions
pop_front,push_front ?
sachant que la stack peut etre adapté aux containers vector, list et deque,
et que ces containers ont des fonctions qui peuvent tout a fait faire une
stack si on les utilise.
--
Cordialement,
Heinquoi
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
-- Loïc
heinquoi wrote:
Bjr,
j'ai une question con...je peux ?
voici
quel est intérêt de la stack lorsque les container on déjà des fonctions
pop_front,push_front ?
sachant que la stack peut etre adapté aux containers vector, list et deque,
et que ces containers ont des fonctions qui peuvent tout a fait faire une
stack si on les utilise.
Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un
puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
-- Loïc
heinquoi
"Loïc Joly" a écrit dans le message de news:cam1cl$qpn$
quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un
puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
ok, merci cordialement H
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:cam1cl$qpn$1@news-reader5.wanadoo.fr...
quel est intérêt de la stack lorsque les container on déjà des fonctions
pop_front,push_front ?
Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un
puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
"Loïc Joly" a écrit dans le message de news:cam1cl$qpn$
quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? Elle n'offre QUE l'interface d'une stack, et évite ainsi que quelqu'un
puisse regarder ce qui se passe à l'intérieur et cass cette abstraction.
ok, merci cordialement H
Michel Michaud
Dans news:40ce3113$0$13823$,
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction. Si ce n'est pas assez clair, demande-toi pourquoi il y a la classe std::list dans la bibliothèque puisqu'on peut implémenter tout ça avec les simples pointeurs et new... On aime ne pas avoir plus que nécessaire et avoir l'interface la plus proche de notre abstraction.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:40ce3113$0$13823$626a14ce@news.free.fr,
j'ai une question con...je peux ?
voici quel est intérêt de la stack lorsque les container on déjà
des fonctions pop_front,push_front ?
sachant que la stack peut etre adapté aux containers vector,
list et deque, et que ces containers ont des fonctions qui
peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction.
Si ce n'est pas assez clair, demande-toi pourquoi il y a la
classe std::list dans la bibliothèque puisqu'on peut implémenter
tout ça avec les simples pointeurs et new... On aime ne pas avoir
plus que nécessaire et avoir l'interface la plus proche de notre
abstraction.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction. Si ce n'est pas assez clair, demande-toi pourquoi il y a la classe std::list dans la bibliothèque puisqu'on peut implémenter tout ça avec les simples pointeurs et new... On aime ne pas avoir plus que nécessaire et avoir l'interface la plus proche de notre abstraction.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
Franck Branjonneau writes:
| Samuel Krempp écrivait: | | > faire un push() conserve la validité des | > itérateurs dans un stack ou pas ? et pour pop() ? | | La question est mal posée : une std::stack<> n'a pas d'itérateur.
Ce qui, ÀMÀ, est une kolossale erreur. Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux std::vector. Pas plus tard qu'hier, un de nos étudiants se posait la même question : comment itérer sur un std::stack sans avoir à faire des opérations destructrices. (Il utilisait std::tack<xxx::Scope*> et voulait implémenter des règles de look-up).
Il n'y a pas de mystère sur ce que fait un push() ou un pop(): Ils transforment ça en un push_back() et un pop_back(). L'invalidation des itérateurs s'en suit comme conséquence: (1) si tu adaptes un machin qui ressemble à un vecteur, t'as des problèmes. (2) si tu adaptes un machin qui ressemble à une liste, t'as pas de problèmes.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> écrivait:
|
| > faire un push() conserve la validité des
| > itérateurs dans un stack ou pas ? et pour pop() ?
|
| La question est mal posée : une std::stack<> n'a pas d'itérateur.
Ce qui, ÀMÀ, est une kolossale erreur. Plusieurs fois, j'ai abandonné
std::stack pour utiliser le bon vieux std::vector. Pas plus tard qu'hier,
un de nos étudiants se posait la même question : comment itérer sur
un std::stack sans avoir à faire des opérations destructrices.
(Il utilisait std::tack<xxx::Scope*> et voulait implémenter des règles
de look-up).
Il n'y a pas de mystère sur ce que fait un push() ou un pop(): Ils
transforment ça en un push_back() et un pop_back(). L'invalidation des
itérateurs s'en suit comme conséquence:
(1) si tu adaptes un machin qui ressemble à un vecteur, t'as des
problèmes.
(2) si tu adaptes un machin qui ressemble à une liste, t'as pas de
problèmes.
| Samuel Krempp écrivait: | | > faire un push() conserve la validité des | > itérateurs dans un stack ou pas ? et pour pop() ? | | La question est mal posée : une std::stack<> n'a pas d'itérateur.
Ce qui, ÀMÀ, est une kolossale erreur. Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux std::vector. Pas plus tard qu'hier, un de nos étudiants se posait la même question : comment itérer sur un std::stack sans avoir à faire des opérations destructrices. (Il utilisait std::tack<xxx::Scope*> et voulait implémenter des règles de look-up).
Il n'y a pas de mystère sur ce que fait un push() ou un pop(): Ils transforment ça en un push_back() et un pop_back(). L'invalidation des itérateurs s'en suit comme conséquence: (1) si tu adaptes un machin qui ressemble à un vecteur, t'as des problèmes. (2) si tu adaptes un machin qui ressemble à une liste, t'as pas de problèmes.
-- Gaby
Samuel Krempp
le Tuesday 15 June 2004 21:36, écrivit :
Dans news:40ce3113$0$13823$,
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction. Si ce n'est pas assez clair, demande-toi pourquoi il y a la classe std::list dans la bibliothèque puisqu'on peut implémenter tout ça avec les simples pointeurs et new...
enfin c'est pas vraiment la meme chose. Si on veut stocker des choses suivant le concept de liste avec seulement les pointeurs, il va falloir écrire son propre truc, pas complètement trivial.
ce qui surprend l'OP, c'est que le concept de stack est satisfait par deque, et que cependant la norme définit un container stack à part entière, qui n'ajoute aucune propriété par rapport à deque : il a seulement des propriétés en moins.. enfin je ne suis pas sûr, faire un push() conserve la validité des itérateurs dans un stack ou pas ? et pour pop() ?
On aime ne pas avoir plus que nécessaire et avoir l'interface la plus proche de notre abstraction.
soit. m'enfin la norme ne se donne pas la peine d'ajouter une classe partout où elle pourrait le faire juste pour aider le programmeur à exprimer ses intentions, l'existence de <stack> doit probablement bcp au catalogue usuel des concepts de containers classiques.
-- Sam
le Tuesday 15 June 2004 21:36, mm@gdzid.com écrivit :
Dans news:40ce3113$0$13823$626a14ce@news.free.fr,
j'ai une question con...je peux ?
voici quel est intérêt de la stack lorsque les container on déjà
des fonctions pop_front,push_front ?
sachant que la stack peut etre adapté aux containers vector,
list et deque, et que ces containers ont des fonctions qui
peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction.
Si ce n'est pas assez clair, demande-toi pourquoi il y a la
classe std::list dans la bibliothèque puisqu'on peut implémenter
tout ça avec les simples pointeurs et new...
enfin c'est pas vraiment la meme chose. Si on veut stocker des choses
suivant le concept de liste avec seulement les pointeurs, il va falloir
écrire son propre truc, pas complètement trivial.
ce qui surprend l'OP, c'est que le concept de stack est satisfait par deque,
et que cependant la norme définit un container stack à part entière, qui
n'ajoute aucune propriété par rapport à deque : il a seulement des
propriétés en moins..
enfin je ne suis pas sûr, faire un push() conserve la validité des
itérateurs dans un stack ou pas ? et pour pop() ?
On aime ne pas avoir
plus que nécessaire et avoir l'interface la plus proche de notre
abstraction.
soit. m'enfin la norme ne se donne pas la peine d'ajouter une classe partout
où elle pourrait le faire juste pour aider le programmeur à exprimer ses
intentions, l'existence de <stack> doit probablement bcp au catalogue usuel
des concepts de containers classiques.
j'ai une question con...je peux ? voici quel est intérêt de la stack lorsque les container on déjà des fonctions pop_front,push_front ? sachant que la stack peut etre adapté aux containers vector, list et deque, et que ces containers ont des fonctions qui peuvent tout a fait faire une stack si on les utilise.
Comme on t'a répondu ailleurs, c'est une question d'abstraction. Si ce n'est pas assez clair, demande-toi pourquoi il y a la classe std::list dans la bibliothèque puisqu'on peut implémenter tout ça avec les simples pointeurs et new...
enfin c'est pas vraiment la meme chose. Si on veut stocker des choses suivant le concept de liste avec seulement les pointeurs, il va falloir écrire son propre truc, pas complètement trivial.
ce qui surprend l'OP, c'est que le concept de stack est satisfait par deque, et que cependant la norme définit un container stack à part entière, qui n'ajoute aucune propriété par rapport à deque : il a seulement des propriétés en moins.. enfin je ne suis pas sûr, faire un push() conserve la validité des itérateurs dans un stack ou pas ? et pour pop() ?
On aime ne pas avoir plus que nécessaire et avoir l'interface la plus proche de notre abstraction.
soit. m'enfin la norme ne se donne pas la peine d'ajouter une classe partout où elle pourrait le faire juste pour aider le programmeur à exprimer ses intentions, l'existence de <stack> doit probablement bcp au catalogue usuel des concepts de containers classiques.
-- Sam
Franck Branjonneau
Samuel Krempp écrivait:
faire un push() conserve la validité des itérateurs dans un stack ou pas ? et pour pop() ?
La question est mal posée : une std::stack<> n'a pas d'itérateur. -- Franck Branjonneau
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> écrivait:
faire un push() conserve la validité des
itérateurs dans un stack ou pas ? et pour pop() ?
La question est mal posée : une std::stack<> n'a pas d'itérateur.
--
Franck Branjonneau <fasbjx@free.fr>
faire un push() conserve la validité des itérateurs dans un stack ou pas ? et pour pop() ?
La question est mal posée : une std::stack<> n'a pas d'itérateur. -- Franck Branjonneau
Gabriel Dos Reis
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux | > std::vector. | | Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
Oui et non.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrivait:
|
| > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux
| > std::vector.
|
| Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
| Gabriel Dos Reis écrivait: | | > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux | > std::vector. | | Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
Oui et non.
-- Gaby
Franck Branjonneau
Gabriel Dos Reis écrivait:
Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux std::vector.
Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ? -- Franck Branjonneau
Gabriel Dos Reis <gdr@cs.tamu.edu> écrivait:
Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux
std::vector.
Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
--
Franck Branjonneau <fasbjx@free.fr>
Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux std::vector.
Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ? -- Franck Branjonneau
Franck Branjonneau
Gabriel Dos Reis écrivait:
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux | > std::vector. | | Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
Oui et non.
Mon acception du français me permet de lire :
1/ Tantôt oui et tantôt non. OK.
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une meilleure gestion de la mémoire que le std::vector<> lors d'utilisations répétées de push()/pop() ? -- Franck Branjonneau
Gabriel Dos Reis <gdr@cs.tamu.edu> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrivait:
|
| > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux
| > std::vector.
|
| Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
Oui et non.
Mon acception du français me permet de lire :
1/ Tantôt oui et tantôt non. OK.
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des
std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une
meilleure gestion de la mémoire que le std::vector<> lors
d'utilisations répétées de push()/pop() ?
--
Franck Branjonneau <fasbjx@free.fr>
| Gabriel Dos Reis écrivait: | | > Plusieurs fois, j'ai abandonné std::stack pour utiliser le bon vieux | > std::vector. | | Tu utilises des std::vector<> pour tes piles ? pas des std::deque<> ?
Oui et non.
Mon acception du français me permet de lire :
1/ Tantôt oui et tantôt non. OK.
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une meilleure gestion de la mémoire que le std::vector<> lors d'utilisations répétées de push()/pop() ? -- Franck Branjonneau
Loïc Joly
Franck Branjonneau wrote:
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une meilleure gestion de la mémoire que le std::vector<> lors d'utilisations répétées de push()/pop() ?
Tu parlerais de queues, je serais d'accord, mais pour des piles, vector me semble meilleur avec les cas d'utilisation classiques.
-- Loïc
Franck Branjonneau wrote:
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des
std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une
meilleure gestion de la mémoire que le std::vector<> lors
d'utilisations répétées de push()/pop() ?
Tu parlerais de queues, je serais d'accord, mais pour des piles, vector
me semble meilleur avec les cas d'utilisation classiques.
2/ Oui j'utilise des std::vector<> pour mes piles ; non pas des std::deque<>. Et là je m'interroge. Le std::deque<> ne fait-il pas une meilleure gestion de la mémoire que le std::vector<> lors d'utilisations répétées de push()/pop() ?
Tu parlerais de queues, je serais d'accord, mais pour des piles, vector me semble meilleur avec les cas d'utilisation classiques.
