Passage de std::string en paramètre

Bonjour,

J'ai un petit soucis dans une de mes classes. Pour informations je débute la programmation c++ sous linux avec kdevelop. Voila la partie de code posant problème :

Code:

---

1 2 3 4 5

while (!m_file.eof()) { std::getline(m_file, line); if (line.length() == 0) continue; //empty line line = removeComment(line);

---

Et la méthode removeComment :

Code:

---

1 2 3 4 5

std::string CReadFile::removeComment(std::string l) { //trim() if (l.find_last_not_of (" ") != std::string::npos) l.erase (l.find_last_not_of (" ") + 1); if (l.find_first_not_of (" ") != std::string::npos) l.erase (0, l.find_first_not_of (" "));

---

Lorsque j'utilise le débugger pour voir la valeur de ma variable line j'ai "#test". En revanche lorsque je suis dans ma méthode removeComment ma variable l vaut "<\260\366\b<\260\366\bD\344\303\277D\322\366\b\204\322\366\b0\260\366\b\364_\360\267\210\343\303\277<\344\303\277\274\343\303\277D\344\303\277\330\343\303\277\346\305\004\b<\344\303\277\274\343\303\277\b".

Merci pour votre aide.

Cette valeur de l est elle visible avant ou après l'exécution du code de removeComment (point d'arrêt placé avant la première ligne)?

Si avant l'exécution de ce code tu vois la bonne valeur, c'est que c'est ton code est incorrect.

Sinon, c'est bien le passage de paramètres.
Dans ce cas, essaye de passer ta string par référence :

Code:

---

1 2	// dans le while removeComment(line);

---

Code:

---

1 2 3 4 5

void CReadFile::removeComment(std::string& l) { ... }

---

En effet lorsque tu fais appel à ta fonction

Code:

---

void CReadFile::removeComment(std::string l)

---

Ton objet string est recopié, la modification à l'intérieur de ta fonction se font sur cette copie, et à la sortie de ta fonction tu l'objet initial n'est pas modifié
Deux solutions :

• Le passage de paramétre par référence
  
  Code:

  ---

  void CReadFile::removeComment(std::string& l)

  ---

  Tu récupère l'adresse de ton objet original. Inconvénient lorsque tu lit l'appel de la fonction on ne remarque pas que l'objet peut etre modifié. A savoir j'utilise tout le temps le passage par référence pour des appels qui ne modifie pas mes objets, mais préfixé le parametre par const.
  
  Code:

  ---

  void CReadFile::NeModifiePasLeParam(const std::string& l)

  ---

  L'avantage tu passe seulement l'adresse de ton object, ce qui évite la recopie de l'objet.
  
• Le passage de paramétre par pointeur (conseillé par B. Stroustrup)
  
  Code:

  ---

  void CReadFile::removeComment(std::string* pl)

  ---

  Tu récupère l'adresse de ton objet original. Avantage lorsque tu lit l'appel tu passe ta chaine par référence:
  
  Code:

  ---

  std::string l; removeComment(&l);

  ---

  Inconvénient il faut tester le paramètre pour tester la validité du pointeur.
  
  Code:

  ---

  1 2 3 4 5

  void CReadFile::removeComment(std::string* pl) { if ( pl == NULL ) throw BadParameter(); ... }

  ---

Le C/C++ demande une grande maitrise des pointeurs, ne tienquiete pas c'est loin d'être facile mais il faut vraiment en bouffé pour comprendre toutes les subtilités.

Passer une std::string par pointeur est une hérésie. On quitte le C et les char*, c'est pas pour être en C++ avec des std::string*

Citation:

---

Le passage de paramétre par pointeur (conseillé par B. Stroustrup)

---

Référence ?

Citation:

---

Le C/C++ demande une grande maitrise des pointeurs, ne tienquiete pas c'est loin d'être facile mais il faut vraiment en bouffé pour comprendre toutes les subtilités.

---

Non, déjà car le C/C++ n'existe pas.

Le C demande une bonne maitrise des pointeurs car il y en a une utilisation massive. Mais c'est le forum à coté.

Le C++ en fait une utilisation basique et encore sous forme améliorée (pointeur intelligent)

C'est facile :
- si tu dois modifier ta string dans la fonction, alors tu prendras une référence : std::string& s
- si tu ne la modifies pas, alors : const std::string& s

Salut,

Je voudrais juste intervenir sur un point de détail...

J'ai, personnellement, horreur de l'utilisation des mots clés break et continue parce qu'ils brisent le flot d'exécution normal.

Je n'utilise par exemple jamais continue, et n'utilise break que contraint et forcé (lorsque j'écris un test à choix multiple).

Bien sur, ce n'est jamais qu'un avis personnel (que je partage malgré tout avec moi même :D), mais je trouve dommage d'y recourir alors qu'il y a parfaitement moyen de s'en passer uniquement ne inversant le test.

On pourra, bien sur, faire valoir que cela permet, parfois, d'éviter des niveaux d'indentations trop importants, mais, en l'espèce, ton code pourrais très bien se contenter d'un (code non corrigé)

Code:

---

1 2 3 4 5

while (!m_file.eof()) { std::getline(m_file, line); if (line.length() != 0) line = removeComment(line);

---

En outre, il faut savoir que eof() ne vaut vrai que lorsque la fin de fichier a... été dépassée.

L'idéal est donc de profiter de la valeur de std::getline (qui renvoie false si elle n'a pas réussi à lire la ligne) comme valeur de test afin de déterminer s'il faut retourner dans la boucle ou non (cf: l'entrée correspondante de la FAQ).

Cela pourrait prendre la forme de

Code:

---

1 2 3 4 5 6 7 8

while(std::getline(m_file, line) { if(line.size()!=0) { removeComment(line); // où removeComment prend une std::string & /* la suite éventuelle */ } }

---

Citation:

---

Référence ?

---

"Le langage C++ par B.Strouptrup"

Citation:

---

Non, déjà car le C/C++ n'existe pas.

---

A je voulais parler du langage C ou C++. D'ailleurs malgrès les puristes qui d'ailleurs me chauffe et qui n'apporte rien. Lorsque l'on fait du vrai C++ dans la vie on est toujours amené à d'interfacer avec du C (autant dans le monde Windows que Linux)

Citation:

---

Le C demande une bonne maitrise des pointeurs car il y en a une utilisation massive. Mais c'est le forum à coté.

---

Bon ben je te conseille de relire mon livre de chevet "Le langage C++ par B.Strouptrup" il n'y fait référence à aucun utilisation pointeur dedans! Même par pour l'héritage !

Citation:

---

Le C++ en fait une utilisation basique et encore sous forme améliorée (pointeur intelligent)

---

A un truc intéressant.
Pour conclure, j'ai souvent dit des conneries et je suis le premier à les assumer, quand on argumente. Notre but est le même, partager notre connaissance, on a pas tous les mêmes habitudes, mais argumentons dessus pour que les autres choisient celles-qui lui conviennent le plus.

Citation:

---

Envoyé par themadmax

"Le langage C++ par B.Strouptrup"

---

J'ai le Stroustrup sous les yeux là, tu pourrais donner le chapitre ?

Citation:

---

Envoyé par Arzar

J'ai le Stroustrup sous les yeux là, tu pourrais donner le chapitre ?

---

Je l'ai et le relis des passages de temps en temps, depuis 5 ans, et je ne me souviens pas d'un tel passage, bizarrement.

Citation:

---

Envoyé par Alp

Je l'ai et le relis des passages de temps en temps, depuis 5 ans, et je ne me souviens pas d'un tel passage, bizarrement.

---

Citation:

---

Chapitre 5.5 Référence
Pour qu'un programme ne soit pas trop difficile à comprendre, il est souvent préférable d'éviter les fonctions qui modifient leurs arguments. Il est préférable de renvoyer explicitement une valeur depuis la fonction ou d'exiger un argument pointeur :

Code:

---

1 2 3 4 5 6 7

int next(int p) { return p+1; } void incr(int* p) { (*p)++; } void g() { int x = 1; increment(x); x = next(x); incr(&x);

---

Contrairement à des notations telles que x=next(x) et incr(&x), increment(x) n'indique pas clairement au lecteur que la valeur de x est en cours de modification.

---

B. Stroustrup Le Langage C++ (Edition spécial, revue et corrigée) Pearson Education

Mais encore une fois, j'aurai préférer passé ce temps a aider ce forumeur débutant, que de recopier des bouquins. Après si tu argumenter ta version je parie que cela serai plus constructif que de savoir qui a raison !

Nan mais c'e n'est pas un encouragement à utiliser les pointeurs.

Les pointeurs sont une calamité. Il faut toujours tester la nullité et on quasiment toujours obligé d'aller voir le code la fonction pour savoir ce qu'elle fait avec.

De plus, en passant un pointeur, on ne sais pas si tu passe un objet ou un tableau C like (ok argument de merde pour un C++ moderne (y'a les vector) mais avec tout le "C With classes" qui existe, il tient).

A l'inverse, avec une référence non constante, tu es sûr que ta fonction va modifier ton objet. Aucun test de non nullité à faire et aucune ambiguïté possible.

Enfin, sur la gestion des effets des bords, c'est à voir au cas par cas: certains fonctions on bien raison d'utiliser des effets de bord, d'autres pas.

Citation:

---

Après si tu argumenter ta version je parie que cela serai plus constructif que de savoir qui a raison !

---

Bah si on peut lui éviter de lui apprendre des inepties, ca sera très constructif pour lui (et pour toi au passage).

Quelque part, c'est bien la preuve que, soit B Stroutroup peut lui aussi dire des c..., soit que le traducteur (qui, il faut l'admettre, est rarement un guru du C++, quand il est effectivement programmeur) s'est royalement vautré et a inversé le sens du texte original ;)

Il n'y a, effectivement, aucun sens à passer un type primitif par référence, et, dans ce cas, je préférerais une fonction renvoyant le type ad-hoc, à une fonction prenant un pointeur vers un type primitif.

Par contre, tu trouvera énormément de monde, même parmi les autres sommités du C++, pour conseiller de donner la préférence au passage par référence en ce qui concerne les types définis par l'utilisateur.

De plus, que ce soit l'auteur ou le traducteur, ce passage oublie un point à mon sens capital qui est... le choix d'un nom cohérent pour la fonction, qui, seul, est normalement bien plus à même de donner l'information sur l'éventuelle modification interne d'un argument qu' un & ou qu'un * pouvant passer inaperçu dans le code.

Effectivement, si tu nomme ta fonction foo ou bar, il te sera difficile de déterminer si l'argument passé est modifié ou non, par contre, si tu la nomme incr ou, mieux, increment, il ne reste strictement aucun doute sur le but de la fonction ;)