iterator.end() ne detecte pas fin de la string

**cyclone3** · 08/06/2006, 20h35

Bonjour,

J'essaye de lire une chaîne de caracteres, et je fais un test pour détécter la fin de la chaîne grace à un itérateur (iterator.end() ) mais le programme ne détécte pas la fin de la chaîne.

J'ai pourtant utilisé iterator comme indiqué sur tous les sites internet...

J'ai encore fait une betise ??

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
#include <string>
#include <iostream>
#include <ctype.h>
int main()
{
 std::string paragraphe="un deux trois.";
 std::string::iterator iter; 
 iter=paragraphe.begin();
 int j=0;
 
 while ( iter!= paragraphe.end()) 
  {
       //si le caractere est imprimable
       if(!iscntrl(paragraphe[j]))
       {  std::cout<<paragraphe[j];
          j++;
       }
  }
 system("PAUSE");
 return EXIT_SUCCESS;
}

**MatRem** · 08/06/2006, 20h37

Il semblerait que tu oublies d'incrémenter ton itérateur

En plus tu n'as pas besoin d'utiliser une variable j, tu dois pouvoir utiliser l'itérateur pour accéder au contenu de la chaîne si je ne m'abuse...

Code :

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

1
2
3
4
5
6
while ( iter!= paragraphe.end()) 
{
       //si le caractere est imprimable
       if(!iscntrl(*iter)) std::cout<<(*iter);
       iter++;
}

A quoi te sert <ctype.h>? Si tu en as vraiment besoin, utilises plutôt <cctype> (même chose, mais pour le c++).

**cyclone3** · 08/06/2006, 20h50

wah...bah ça en fait des betises, en effet...
merci beaucoup pour ton aide !

**Luc Hermitte** · 08/06/2006, 21h15

J'ai tendance à préféer les for() pour ce genre de choses. Moins de risque d'oublier d'incrémenter.

**MatRem** · 08/06/2006, 21h28

J'utilise aussi les for pour ce genre de parcours, on dirait que c'est fait exprés

:

Code :

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

1
2
3
for(iterator=conteneur.begin(); iterator!=conteneur.end(); iterator++){
   //traitements
}

**Jean-Marc.Bourguet** · 08/06/2006, 21h39

Envoyé par Luc Hermitte

J'ai tendance à préféer les for() pour ce genre de choses. Moins de risque d'oublier d'incrémenter.

Tu n'utiliserais pas std::copy pour copier un itérateur filtrant de boost vers un ostream_iterator?

**Luc Hermitte** · 08/06/2006, 22h00

Dans ce cas là ? J'utilise copy_if.

Je n'ai pas encore essayé les itérateurs filtrant j'avoue.

**MatRem** · 08/06/2006, 22h12

Vous voudriez pas donner des exemples de ce dont vous parlez?
Ça peut servir à tous ceux qui ne connaissent pas

**Jean-Marc.Bourguet** · 09/06/2006, 09h50

Envoyé par Luc Hermitte

Dans ce cas là ? J'utilise copy_if.

Il me semblait bien que je l'avais vu quelque part, mais je ne l'avais trouve ni dans boost (ou j'ai mal regarde, je sais) ni dans la norme.

Je n'ai pas encore essayé les itérateurs filtrant j'avoue.

J'en ai ecrit a la main, sans attendre boost.

Je n'ai en fait utilise boost que dans un contexte prive et d'experimentation, au boulot nous utilisons un peu trop de compilateurs avec un support incertain de la norme pour envisager d'essayer

**Jean-Marc.Bourguet** · 09/06/2006, 10h41

Envoyé par MatRem

Vous voudriez pas donner des exemples de ce dont vous parlez?
Ça peut servir à tous ceux qui ne connaissent pas

regarde le contenu de <algorithm> et dans boost, les sections Iterators, Algorithms, Function Objects and higher-order programming, Template Metaprogramming. Ca devrait t'occuper les prochaines annees.

En fait, on fait allusion a des techniques utilisees dans des langages fonctionnels, mais que je n'arrive pas a considerer comme naturelles quand je fais du C++ (ce n'est pas un manque de familiarite, ce sont celles que j'utilise quand j'ecris dans un langage fonctionnel).

Dans l'exemple on devrait pouvoir arriver a une ecriture du genre:

Code :

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

copy_if(ostream_iterator(cout), v.begin(), v.end(). !iscntrl(_1));

en utilisant toutes les ressources que j'ai donnee. Si tu te limites a certaines, ca devient plus complique. De toute maniere, pour etre sur du resultat, il faut bien comprendre a la fois les templates et la gestion de la surchage, deux des points les plus compliques du C++ (je ne maitrise les details ni de l'un, ni de l'autre).

**MatRem** · 09/06/2006, 14h12

merci

L'écriture est plus condensée, c'est sur.
Mais au niveau des performances y a t'il des différences?

J'ai pas encore pris le temps d'utiliser boost, mais on dirait que c'est quand même bien intéressant...

**Laurent Gomila** · 09/06/2006, 17h32

Mais au niveau des performances y a t'il des différences?

C'est principalement de la méta-programmation, donc après compilation le code généré est exactement que ce que tu aurais écrit toi-même.

Et puis pour ce genre de programme les performances sont-elles réellement importantes ? ...

J'ai pas encore pris le temps d'utiliser boost, mais on dirait que c'est quand même bien intéressant...

Très. Surtout que beaucoup de ses bibliothèques seront intégrées au prochain standard.

**MatRem** · 09/06/2006, 20h23

Ce nouveau standard on en entend souvent parler, mais est ce quelqu'un sait quand il aboutira?

**Jean-Marc.Bourguet** · 09/06/2006, 20h47

Envoyé par MatRem

Ce nouveau standard on en entend souvent parler, mais est ce quelqu'un sait quand il aboutira?

On veut le publier en 2009. Donc fin 2007 il devrait avoir des brouillons très proches de ce qui sera publié.

Plus intéressant, quand est-ce qu'on aura les premiers compilateurs conformes... et quand est-ce qu'on pourra compter dessus?

En ce qui concerne C++98, le premier compilateur conforme fut disponible au public en 2003. Et on ne peut toujours pas compter sur le fait d'avoir un compilateur conforme mais le gros de la norme est généralement implémenté; les problèmes principaux étant la gestion d'export et la gestion de la recherche des noms en deux phases. La situation est relativement satisfaisante.

**MatRem** · 10/06/2006, 10h43

On veut le publier en 2009

C'est que tu travailles sur la norme?

On peux encore utiliser boost, alors en attendant ce standard

**Luc Hermitte** · 10/06/2006, 18h33

Envoyé par Jean-Marc.Bourguet

Il me semblait bien que je l'avais vu quelque part, mais je ne l'avais trouve ni dans boost (ou j'ai mal regarde, je sais) ni dans la norme.

Je l'avais croisé dans le MEC++ pour la première fois. Et une recherche sur boost::copy_if (qui n'existe pas) pointe sur une implémentation accompagnée d'un petit commentaire comme quoi copy_if aurait été oublié dans le standard de 98 -- une inattention de ce que j'ai compris.

Envoyé par Jean-Marc.Bourguet

Je n'ai en fait utilise boost que dans un contexte prive et d'experimentation, au boulot nous utilisons un peu trop de compilateurs avec un support incertain de la norme pour envisager d'essayer

Un projet qui "vient" de démarrer nous permet de l'utiliser

Sinon, côté perf, c'est effectivement pareil que le même code écrit à la main et directement (il peut ne même pas y avoir le coût d'un appel de fonction). Plus quelques mineurs avantages (p/r aux implémentations manuelles) : cont.end() n'est évalué qu'une seule fois ; pour les quelques cas où cela fait encore une différence la pré-incrémentation est utilisée. J'ai un squelette de code qui fait que j'ai les mêmes "optims" en quelques touches frappées sur mon clavier.

Je préfère ces écritures quand ce que je réalise des traitements simples qui tiennent en moins d'une ligne de boost::bind. Au delà, je développe rapidement.

Pour le C++09, les USENautes sont globalement au courant. De même que d'autres ici même. Ca fait parti de l'actu C++.

**Jean-Marc.Bourguet** · 11/06/2006, 11h30

Envoyé par Luc Hermitte

Je l'avais croisé dans le MEC++ pour la première fois. Et une recherche sur boost::copy_if (qui n'existe pas) pointe sur une implémentation accompagnée d'un petit commentaire comme quoi copy_if aurait été oublié dans le standard de 98 -- une inattention de ce que j'ai compris.

Il est dans mpl.

Un projet qui "vient" de démarrer nous permet de l'utiliser

Nos projets démarrent avec la nécessité de tourner sur une dizaine de cibles (on compte 32/64 bits comme deux cibles), avec des compilateurs imposés et en récupérrant au minimum un ou deux millions de lignes de code, au maximum, c'est en s'intégrant dans des systèmes avec plusieurs dizaines de millions de lignes de code.

**Jean-Marc.Bourguet** · 11/06/2006, 11h49

Envoyé par MatRem

C'est que tu travailles sur la norme?

Non, je ne peux pas réellement prétendre que je travailles dessus

J'ai juste l'oportunité de voir les choses d'un peu plus près que ce qui est publiquement disponible (par exemple à http://www.open-std.org/jtc1/sc22/wg21/) mais ce n'est pas grand chose... toute l'info que j'ai donnée est disponible d'ailleurs.

On peux encore utiliser boost, alors en attendant ce standard

Même après.

**MatRem** · 11/06/2006, 11h55

En parlant de open-std.org, j'ai essayé de chercher des documents qui présentent la norme du c++ 98 et de sa mise à jour 2003.

Je n'ai trouvé aucun document de synthèse, est ce que quelqu'un aurait des liens?

**Jean-Marc.Bourguet** · 11/06/2006, 13h05

Envoyé par MatRem

En parlant de open-std.org, j'ai essayé de chercher des documents qui présentent la norme du c++ 98 et de sa mise à jour 2003.

Je n'ai trouvé aucun document de synthèse, est ce que quelqu'un aurait des liens?

Pour la version définitive et imprimée:

http://www.amazon.fr/exec/obidos/ASI...130112-2724202

Pour ce que je pense être le dernier brouillon public:

http://www.open-std.org/jtc1/sc22/wg...ers/2001/n1316

iterator.end() ne detecte pas fin de la string

C++

Discussions similaires

Partager

Partager