Discussion :

[Rick_Cplusplus]

Bonjour la communauté,

Si je code ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
bool b;
std::string route="010010";
std::string rte="";
for(int i(0); i<6; i++)
{
	rte=route[i];
	if(rte=="0") b=false;
	if(rte=="1") b=true;
	// fait des trucs avec b
}

le compilateur (Mingw avec Code::Blocks) ne dit rien.

Mais si je code ainsi (pour économiser la variable rte qui ne sert apparemment pas à grand chose) :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
bool b;
std::string route="010010";
 
for(int i(0); i<6; i++)
{
	if(route[i]=="0") b=false;
	if(route[i]=="1") b=true;
	// fait des trucs avec b
}

le compilateur m'accuse de comparer des choses incomparables :

warning: comparison with string literal results in unspecified behaviour [-Waddress]|
error: ISO C++ forbids comparison between pointer and integer [-fpermissive]|

Je ne comprends pas trop quelle est la différence entre ces 2 codes qui, dans mon esprit, devraient produire le même comportement, i.e. déterminer le booléen true ou false suivant que le charactère n°i de la chaîne route vaut "0" ou "1"...
Où donc me plante-je ?

Rick.

[Bousk]

std::string::operator[] retourne un char.
" est le délimiteur de chaînes de caractères.
' est le délimiteur de caractère.
Le premier code est très médiocre.

[Rick_Cplusplus]

Oki ; donc le "bon code" ce serait ça ?

Code :

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

1
2
3
4
5
6
7
8
9
 
bool b;
std::string route="010010";
for(int i(0); i<6; i++)
{
	if(route[i]=='0') b=false;
	if(route[i]=='1') b=true;
	// fait des trucs avec b
}

Question subsidiaire, quelle différence avec :

Code :

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

1
2
3
 
if(route.at(i)=='0') b=false;
if(route.at(i)=='1') b=true;

Une question de goût ?
Rick.

[koala01]

Salut,

A vrai dire, tu pourrais même simplifier encore le code, à partir du moment où tu as la certicude (qu'il te faudra acquérir ) que ta chaine de caractères ne contient que des "0" et des "1".

Car, tant que tu as cette certitude (qui est facile à obtenir), tu peux partir du principe que "si on n'a pas un ''1'', c'est qu'on a un ''0'' ", si bien que le code "idéal" serait sans doute proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
for(size_t i = 0;i<route.size();++i){// size_t parce que les indice sont d'office non signés
                                     //route.size(), pour s'assurer que l'on n'essaye pas d'accéder à des caractères qui n'existent pas ;) 
    bool isOne{route[i]=='1'} ; // 1- on déclare les données au plus proche de leur utilisation réelle, et, autant que possible, en leur donnant tout de suite la valeur cohérente qui convient ;)
           // 2 - on donne, autant que faire se peut, un nom qui indique l'usage qui sera fait des fonctionnalités que l'on utilise
    if(isOne){
         /* que faire si on avait "1" */
    }else{
        /* que faire si on avait "0"
    }
}

Et, à partir de là, on peut même encore simplifier le code pour lui donner la forme de

Code :

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

1
2
3
4
5
6
7
8
9
or(size_t i = 0;i<route.size();++i){// size_t parce que les indice sont d'office non signés
                                     //route.size(), pour s'assurer que l'on n'essaye pas d'accéder à des caractères qui n'existent pas ;) 
 
    if(route[i]=='1'){
         /* que faire si on avait "1" */
    }else{
        /* que faire si on avait "0"
    }
}

Pour répondre à la question subsidiaire, les fonctions at() sont de pures aberrations qui n'auraient jamais du être insérée dans la bibliothèque standard

Pour faire simple, elles traient une erreur de logique (le développeur essaye d'accéder à un élément qui n'existe pas), comme s'il s'agissait d'une situation à laquelle le développeur est dans l'incapacité d'échapper et dont il doit tenir compte "plus haut dans la pile d'appels" (en lançant une exception).

Le pire étant que le test qu'elle effectuera pour s'assurer que cette erreur ne survient pas sera aussi effectué en production, alors que l'erreur aurait du être corrigée depuis longtemps

Ce n'est donc pas juste "une question de goût" : c'est une réaction "viscérale", conceptuellement justifiée suite à une meilleur compréhension des enjeux que celle qui avait cours lors de la mise au point de la bibliothèque standard (qui date quand même des année '90)

[Bktero]

std::string::operator[] retourne un char. .

Bien vu !

Pour expliciter les conséquences :

Code 1
rte=route[i]; à droite, on a un caractère, à gauche une std::string et il existe un opérateur légal d'affectation (voir forme 4 https://fr.cppreference.com/w/cpp/st...ng/operator%3D)
rte=route[i]if(rte=="0") on compare une std::string à un const char* et il existe un opérateur légal de comparaison (sans doute en construisant une std::string temporaire et en comparant ensuite les 2 std::strings)

Code 2
if(route[i]=="0") on compare un char (qui est un entier = integer en anglais) à un const char* (qui est un pointeur)
// au final, on a donc bien une comparison between pointer and integer

[Rick_Cplusplus]

Merci à tous pour vos explications.

(...) A vrai dire, tu pourrais même simplifier encore le code, à partir du moment où tu as la certicude (qu'il te faudra acquérir ) que ta chaine de caractères ne contient que des "0" et des "1". (...)

=> J'ai effectivement cette certitude, la chaîne est crée par un constructeur d'objet. ^^

Code :

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

1
2
3
 
for(size_t i = 0;i<route.size();++i) // size_t parce que les indice sont d'office non signés
                                     //route.size(), pour s'assurer que l'on n'essaye pas d'accéder à des caractères qui n'existent pas ;)

=> Bien vu le "route.size()"

// on déclare les données au plus proche de leur utilisation réelle, et, autant que possible, en leur donnant tout de suite la valeur cohérente qui convient

Oui alors du coup je rebondis là dessus :

la déclaration "au plus près" se fait dans ce cas au sein d'une boucle. Je me demande quel est le comportement :
- la variable est redéclarée (un genre de var[i]) et le compilateur gère ça tout seul ? si oui ça peut ponctuellement générer de l'espace mémoire utilisé "pour rien" vu que var[i-1] ne sert plus à rien...
- la variable est détruite à chaque itération lors de l'atteinte de "}" de la boucle et est re-crée lors de l'itération suivante ? Si oui alors c'est du temps de cycle en plus par rapport à une déclaration juste en amont de la boucle...
c'est sans doute métaphysique comme question vu la puissance des machines mais comme je me la pose depuis un bon moment, s'il y a moyen d'avoir une réponse...

Rick.

[Bousk]

Code :

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

1
2
for(size_t i = 0;i<route.size();++i){// size_t parce que les indice sont d'office non signés
                                     //route.size(), pour s'assurer que l'on n'essaye pas d'accéder à des caractères qui n'existent pas ;)

Allons Koala, nous sommes en 2019 for (char c : route) est encore plus sûr.

la déclaration "au plus près" se fait dans ce cas au sein d'une boucle. Je me demande quel est le comportement :
- la variable est redéclarée (un genre de var[i]) et le compilateur gère ça tout seul ? si oui ça peut ponctuellement générer de l'espace mémoire utilisé "pour rien" vu que var[i-1] ne sert plus à rien...
- la variable est détruite à chaque itération lors de l'atteinte de "}" de la boucle et est re-crée lors de l'itération suivante ? Si oui alors c'est du temps de cycle en plus par rapport à une déclaration juste en amont de la boucle...
c'est sans doute métaphysique comme question vu la puissance des machines mais comme je me la pose depuis un bon moment, s'il y a moyen d'avoir une réponse...

On s'en moque pas mal. Tu passes d'un code qui faisait des copie, création et comparaison de string à "oui mais le nombre de cycles cpu alors ?"
Si tu te souciais vraiment des performances le premier code n'aurait jamais vu le jour. Et de toute façon non tu n'as pas besoin de courir après les performances à ce point.
Une variable ça n'existe pas, c'est juste un artefact pratique à manipuler quand on écrit le code.
Le compilateur il ne traite que des adresses, et il sera assez intelligent pour réserver la mémoire nécessaire, et l'optimiser au passage.
char c; ne crée rien. Ça va à peine réserver une adresse dans la stack. Ça ne construit rien non plus, les variables de type primitif ne sont pas construites par défaut contrairement à une classe.
C'est pour ça qu'une variable a une valeur aléatoire par défaut.

[Bktero]

le compilateur gère ça tout seul ? si oui ça peut ponctuellement générer de l'espace mémoire utilisé "pour rien" vu que var[i-1] ne sert plus à rien...

Si nous, pauvres petits développeurs, nous sommes posé cette question, alors il est évident que le compilateur aussi. Il est bien plus fort que nous pour optimiser du code alors laissons-le faire.

Il y a une petite condition pour cela : écrire le code le plus simple possible. Eviter de faire des pseudo-optimisations en se disant "je vais orienter le compilateur". N'oublions pas que le compilateur est écrit par des humains pour reconnaître des patterns.......que des humains ont identifié. Si tu fais un code trop alambiqué, ton compilateur risque de se dire "mais qu'est ce que ça veut dire?... aucune idée, faisons une traduire naïve (ndlr : et donc peu optimisée)".

Allons Koala, nous sommes en 2019 for (char c : route) est encore plus sûr.

Et tellement plus clair