Discussion :

[monodev]

bonsoir a tous.
est ce qu'on pourrait parcourrir une liste de la stl sans utiliser un iterateur.

[Haze.]

Nope, les itérateurs ont été justement conçus pour le parcours des conteneurs de la STL.
Quel est le problème avec ta std::list ?

[monodev]

merci pour la reponse.

le principe de la liste chainee,c'est qu'elle contient des noeuds,chaque noeud pointant vers le noeud suivant,chose qui assure ce chainage puisue le parcours se fait simplement via une methode qui ne fai qu'affecter au noeud courrant l'adresse du suivant de l'ex courrant.
ma question est:
est ce que la list de la stl n'est pas munie d'une telle methode next().
Merci.

[krieg]

Salut,
non, il n'y a pas de méthode next() sur les listes stl.
mais tu peux creer une liste stl avec des element d'une classe dans laquel tu peux implanter ta méthode next().
si tu souhaites en savoir plus :
http://cpp.developpez.com/faq/cpp/?page=STL

bye

[monodev]

merci pour la reponse.
mais, je ne pense pas que le fait de munir les elements de la liste d'une telle methode marcherait.et je ne vois pas comment pourrait on concevoir cela.
si par exemple on a une liste de points,sachant que point est defini dans une classe a part.
implanter une methode next() pour la classe point n'aurait vraiment pas de signification.
vous etes pas d'accord avec moi?

[Arzar]

est ce que la list de la stl n'est pas munie d'une telle methode next().

Si, en quelque sorte, par le biais d'un itérateur.

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
 
// Habituellement pour parcourir une liste on fait :
Node * node = head;
while(node)
{
    node->DoStuff();
    node = node->next();
}
 
// Alors qu'avec la STL on fait :
std::list<Point>::iterator it = liste.begin();
while(it != liste.end()
{
   it->DoStuff();
   it++;
}
 
// Ceci dit la notation usuelle, que tu retrouveras dans les tutos sur la STL est plutôt :
for(std::list<Point>::iterator it = liste.begin() ; it != liste.end() ; ++it)
{
   it->DoStuff();
}

liste.begin() est l'équivalent du pointeur de tête
liste.end() est l'équivalent du pointeur null en fin de liste.
it++ est l'équivalent de node = node->next();

[monodev]

merci pour la reponse.

[3DArchi]

Ou encore, pour être 100% STL:

Code :

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

1
2
3
4
5
6
 
std::for_each(
   liste.begin(),
   liste.end(),
   std::mem_fun_ref(&Point::DoStuff)
);

[Arzar]

mem_fun_ref c'est pour les low.
Le true-STL-spirit c'est ça :

Code :

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

1
2
 
std::for_each(liste.begin(), liste.end(), [](Point& p){p.DoStuff()});

Lambdaaaa powwwwwwwwaaahh !!!

[3DArchi]

mem_fun_ref c'est pour les low.
Le true-STL-spirit c'est ça :

Code :

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

1
2
 
std::for_each(liste.begin(), liste.end(), [](Point& p){p.DoStuff()});

Lambdaaaa powwwwwwwwaaahh !!!

C'est du boost pas du STL, non?

[Davidbrcz]

futur STL de C++0X avec les lambdas-expressions.

[Arzar]

Garanti 100 % STL, dans quelques années
Ceci dit, Visual studio 2010 aura les lambdas, et leur développement est en cours pour gcc.
Et toujours à propos des lambdas, un des ingénieurs de Microsoft a pondu un post fantastique sur le blog de visual studio qui explique en détails la syntaxe et l'utilisation des lambdas d'une manière vraiment claire et pédagogique. Détail amusant, le post a été écrit par Stephan T. Lavavej, clairement l'homme de la situation!

[ram-0000]

mem_fun_ref c'est pour les low.
Le true-STL-spirit c'est ça :

Code :

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

1
2
 
std::for_each(liste.begin(), liste.end(), [](Point& p){p.DoStuff()});

Et cela rend le code plus lisible ?
Ou alors, c'est sponsorisé par les laboratoires Boiron, parce que là, il faut un tube d'aspirine pour comprendre ce qui se passe

[Davidbrcz]

Et cela rend le code plus lisible ?
Ou alors, c'est sponsorisé par les laboratoires Boiron, parce que là, il faut un tube d'aspirine pour comprendre ce qui se passe

Ca allège le code car ca évite d'écrire un foncteur.
Par contre, j'admets que la syntaxe n'est pas des plus jolie, mais cela ne reste qu'une syntaxe et une fois le 1er choc passé, c'est simple et efficace

[Alp]

Sinon, en rendant la lambda expr moins succinte, tu peux la rendre plus compréhensible.

Par contre, je ne veux pas dire, mais next() ça revient à utiliser std::advance() en donnant 1 comme argument pour la "distance"...

[IrmatDen]

Et cela rend le code plus lisible ?
Ou alors, c'est sponsorisé par les laboratoires Boiron, parce que là, il faut un tube d'aspirine pour comprendre ce qui se passe

Faut voir plus loin que l'exemple donné; le code est nettement plus lisible lorsque l'expression n'est pas remplaçable par un mem_fun_ref ou autre binders, mais uniquement par une fonction/foncteur (tout en restant dans le cas de besoins triviaux et/ou locaux).

[monodev]

S'il vous plait,
syntaxe de advance(),si c'est possible!!

[IrmatDen]

ça ?

Edit: mais si tu ne veux vraiment pas utiliser les itérateurs pour quelque raison que ce soit (prof ?), bah, tu fais une bonne vieille boucle for

[Arzar]

Monodev, deux adresses très pratiques :
C++ reference
Le site de SGI (pour la STL)

Et cela rend le code plus lisible ?
Ou alors, c'est sponsorisé par les laboratoires Boiron, parce que là, il faut un tube d'aspirine pour comprendre ce qui se passe.

Héhéhé, bon c'est vrai que la première fois, ça fait un choc : "Mais qu'est ce que ce [] vient f***** là ?!?"

Mais au final, oui je trouve ça pas si mal. Le parallèle entre fonction classique et lambda est très clair :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
foo(Point& p)
{
   p.DoStuff();
}
 
[](Point& p)
{
   p.DoStuff();
}
 
// d'ou le
for_each(liste.begin(), liste.end(), [](Point& p) { p.DoStuff(); });

L'avantage, c'est que l'on voit directement sur quoi l'on travaille (des Point&) et comment (p.DoStuff()). Plus besoin d'aller et venir pour vérifier la définition d'un foncteur, plus besoin de bind_mem_ptr_fun_2nd<std::unary_function> pour appeler des fonctions membres d'un objet, il y a quand même du progrès.

Sinon, en rendant la lambda expr moins succinte, tu peux la rendre plus compréhensible.

Ben, je préfère quand même les lambdas très simple, que l'on peut "parser" en un coup d'œil, mais c'est vrai que les exemples données dans l'article du blog de vs utilisent une mise en page sur plusieurs lignes qui donnent une assez bonne lisibilité:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
std::vector<int> v = {10, 2, 13, 4, 5};
int x = 1;
int y = 1;
for_each(v.begin(), v.end(), [&](int& r) 
{
   const int old = r;
   r *= x * y;
   x = y;
   y = old;
});

Ceci dit, dès que ça se complique un peu, ça devient très vite assez perturbant:

Code :

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

1
2
3
4
5
6
7
 
std::erase(remove_if(v.begin(), v.end(), [](Point& p) {
   p.Update();
   if(p.Valid() == false)
      return true;
   return false;
}), v.end());

[JolyLoic]

Et cela rend le code plus lisible ?

Pour un for_each, pas vraiment à mon sens. En tout cas moins que (puisqu'on reste en C++0x) :

Code :

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

1
2
3
4
for (Point&p : liste)
{
    p.doStuff();
}

Par contre, pour d'autres algorithmes, comme un remove_each, un sort,... ça le deviens à mon sens.

Ou alors, c'est sponsorisé par les laboratoires Boiron, parce que là, il faut un tube d'aspirine pour comprendre ce qui se passe

Vu que Boiron, c'est de l'homéopathie, c'est à dire de l'eau sucrée, c'est que ce n'est pas si prise de tête que ça...