Discussion :

[coyotte507]

Salut,

ça veut juste dire que tu utilises deux fois le même nom pour tes variables.

[Nyko17]

haha quel bougre d'âne je fais! Vive moi

ou pas...

[r0d]

Pour moi la première fonction est préférable à tous points de vue. Les classes de la STL sont très utiles, mais je ne vois aucune raison valable de ne pas utiliser certaines fonctions du C pur, quand c'est plus pratique, plus court, et plus performant.

La raison principale est la sémantique.

Reprenons dans l'ordre tes arguments:
- plus pratique
c'est, à mon avis, une interprétation personnelle. J'ai l'habitude d'utiliser les flux, et pour moi, par le fait même de cette habitude, il m'est plus pratique d'utiliser les flux.

- plus court
c'est un argument valable, mais il ne se suffit pas à lui-même. Souvent, à vouloir faire du code très court il en devient illisible. Dans le cas d'un code qui génère le même asm, je préfère un code d'une ligne de plus et plus lisible, plus sémantiquement correct, qu'un code de une ligne moins explicite.

- plus performant
il faut bien comprendre que dans 99% des questions posées sur ce forum, et dans 80% du code professionnellement écrit chaque jours, les performances ne sont pas importante. Malgrès que ce soit une problématique passionnante, je crois il ne faut pas se focaliser là-dessus (sauf exception - sans mauvais jeu de mot ).

En revanche, ce qui me parait plus important, c'est la sémantique. Conserver une bonne sémantique permet de:
1/ Bien utiliser et comprendre les concepts du langage qu'on utilise.
2/ Fournir aux gens qui vont lire nos sources (souvent nous-même) un code lisible et cohérent.
3/ Améliorer la modularité de son code sans avoir même à y penser. Le concept même de modularité (en ingénierie générale, pas seulement en développement logiciel) est né sur la notion de standard. En respectant les standard, on se place de fait, sans même y penser, dans un cadre de modularité.

Un exemple concret pour ce 3eme point qui peut paraître un argument fumeux "philosophique" bref, bidon:
En utilisant les flux pour ses conversions et pour la lecture de son fichier, cet utilisateur se serait sans doute rendu compte qu'il pouvait (comme l'a noté Le Farfadet Spatial) directement lire ses données en tant qu'entiers, et non en tant que chaines de caractères. Et là on y gagne à tous les niveaux (taille du code, performance, sémantique, modularité, maintenabilité...)

Il ne faut pas non plus être extrêmiste, mais le respect des standards et de la philosophie du langage qu'on utilise me parait bon dans le sens où cela résous, sans même qu'on ait besoin d'y penser, beaucoup de problèmes. Cet argumentaire est valable pour bien d'autres points (const conformité, encapsulation, etc...)

That's my point.

[Le Farfadet Spatial]

Salut à tous !

Bon, cela ne fait pas longtemps que j'interviens sur ce forum, donc vous ne me connaissez pas encore, aussi vous préviens-je : j'aime la philosophie. Cela dit, je pense que je n'en rajouterais pas beaucoup plus, dans la mesure où j'ai l'impression que nous disons un peu tous la même chose.

- plus pratique
c'est, à mon avis, une interprétation personnelle. J'ai l'habitude d'utiliser les flux, et pour moi, par le fait même de cette habitude, il m'est plus pratique d'utiliser les flux.

Tout à fait d'accord.

- plus court
c'est un argument valable, mais il ne se suffit pas à lui-même. Souvent, à vouloir faire du code très court il en devient illisible. Dans le cas d'un code qui génère le même asm, je préfère un code d'une ligne de plus et plus lisible, plus sémantiquement correct, qu'un code de une ligne moins explicite.

Pareil, je te rejoins complètement.

- plus performant
il faut bien comprendre que dans 99% des questions posées sur ce forum, et dans 80% du code professionnellement écrit chaque jours, les performances ne sont pas importante. Malgrès que ce soit une problématique passionnante, je crois il ne faut pas se focaliser là-dessus (sauf exception - sans mauvais jeu de mot ).

C'est tellement vrai !

Mon travail, c'est la modélisation. C'est-à-dire que je fais du calcul massif sur ordinateurs : autant dire sans doute une des branches de l'informatique qui est la plus friande de performances (1 % de performances en plus peut faire gagner parfois jusqu'à quelques jours et les calculateurs sont mutualisés). Pourtant, les codes de calculs contiennent assez peu de gros bricolages pour gagner des cycles. D'autant moins que les compilateurs modernes font d'excellentes optimisations, souvent meilleures que ce que peut faire un être humain et le font mieux si le code est proche de l'algorithme, plutôt que de comprendre plein de choses bizarroïdes.

En revanche, ce qui me parait plus important, c'est la sémantique. Conserver une bonne sémantique permet de:
1/ Bien utiliser et comprendre les concepts du langage qu'on utilise.
2/ Fournir aux gens qui vont lire nos sources (souvent nous-même) un code lisible et cohérent.
3/ Améliorer la modularité de son code sans avoir même à y penser. Le concept même de modularité (en ingénierie générale, pas seulement en développement logiciel) est né sur la notion de standard. En respectant les standard, on se place de fait, sans même y penser, dans un cadre de modularité.

Certes, mais dans le cas particulier suivant, cette solution :

Code :

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

1
2
 
const int valeur = std::atoi(argv[1]);

Est-elle moins lisible, modulaire et plus éloignée des concepts du C++ que celle là :

Code :

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

1
2
3
4
5
 
const std::string chaine = argv[1];
std::istringstream ist (chaine);
int valeur;
ist >> valeur;

Je ne le pense pas. En plus, dans le deuxième cas, on perd la possibilité de déclarer « valeur » comme étant constant, ce qui est pourtant est une pratique qui a beaucoup d'intérêt.

Il ne faut pas non plus être extrêmiste, mais le respect des standards et de la philosophie du langage qu'on utilise me parait bon dans le sens où cela résous, sans même qu'on ait besoin d'y penser, beaucoup de problèmes. Cet argumentaire est valable pour bien d'autres points (const conformité, encapsulation, etc...)

En effet.

That's my point.

And you've got one !

À bientôt.

Le Farfadet Spatial

[Le Farfadet Spatial]

Re-salut à tous !

Pour essayer d'être un peu ordonné, je fais un deuxième message, cette fois vraiment directement lié au problème de Nyko17.

Code :

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

1
2
3
4
5
 
#include <sstream>
#include <iostream>
#include <list>
#include <fstream>

Voici la fonction concernée:

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
 
std::string ListeVins::convertiEnIntetAjoute(std::string & Qt1, std::string & Qt2)
{  
	std::istringstream iss( Qt1 );   //ici
	int laQt1;
	iss >> laQt1;	
	std::istringstream iss( Qt2 ); // et là
	int laQt2;
	iss >> laQt2;	
	int res= laQt1 + laQt2;	
    std::ostringstream oss;  
    oss << res;
    std::string result = oss.str();
 
    return result;
}

Au delà du problème d'utiliser plusieurs fois le même nom de variable, ce que tu as bien évidemment corrigé, je pense que tu fais toujours fausse route. Cette idée d'ajouter des entiers stockés sous forme de chaînes de caractères est conceptuellement bancale : soit on a une chaîne de caractère, soit un entier, mais lorsque l'on fait un amalgame entre les deux, alors le typage devient incertain et c'est la source de nombreuses bogues.

À mon avis, il faut que tu abandonnes complètement l'idée d'avoir des chaînes que tu ne convertirais qu'à l'occasion. Au contraire, je te conseille de lire ton fichier ligne par ligne et que tu stockes le résultat à l'aide de quelque chose de ce genre :

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
 
#include <fstream>
#include <string>
#include <sstream>
 
// ...
 
std::ifstream fichier (nomFichier);
if (file.bad()) throw InvalidFile ();
 
std::string chaine;
 
// ...
 
while (file) {
std::getline(fichier, chaine);
if (file.bad()) throw InvalidFile ();
 
// ...
}
 
// ...

Ainsi, tu peux tester le format de chaque ligne de ton fichier. Si dans l'une des lignes du fichier tu trouves la sous-chaîne « Quantité: » alors stocke la valeur de quantité dans un entier. Quelque chose dans ce goût :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
// ...
 
if (chaine.find("Quantité:") != npos) {
  std::istringstream iss (chaine);
  std::string temp;
  int quantite;
  iss >> temp >> quantite;
}
 
// ...

Ainsi, « quantite » est vraiment un entier et fini les bricolages.

À bientôt.

Le Farfadet Spatial

[Nyko17]

Ca marcherait si j'enregistrais les infos de cette manière dans le fichier:

Code :

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

1
2
3
nom: toto
année: 2000
quantité: 2

mais je les enregistre de celle là:

Code :

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

1
2
3
toto
2000
2

Donc je ne peux pas chercher la chaine "quantité:".
Je pourrais donc revoir la façon dont j'enregistre les infos mais j'ai des délais à respecter pour rendre mon projet, et je suis pas en avance, donc je vais rester sur la methode avec sstream qui a l'air de marcher.
Mais merci de l'info

[Le Farfadet Spatial]

Salut à tous !

Ca marcherait si j'enregistrais les infos de cette manière dans le fichier:

Code :

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

1
2
3
nom: toto
année: 2000
quantité: 2

mais je les enregistre de celle là:

Code :

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

1
2
3
toto
2000
2

Donc je ne peux pas chercher la chaine "quantité:".
Je pourrais donc revoir la façon dont j'enregistre les infos mais j'ai des délais à respecter pour rendre mon projet, et je suis pas en avance, donc je vais rester sur la methode avec sstream qui a l'air de marcher.

Mais alors, c'est encore plus simple ! Point n'est besoin de changer la façon de stocker tes données ! Lis tes données par trois :

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
23
 
// ...
 
#include <fstream>
#include <string>
 
// ...
 
std::ifstream fichier (nomFichier);
 
// ...
 
while (fichier) {
  // ...
 
  std::string label;
  int date, quantite;
  fichier >> label >> date >> annee;
 
  // ...
}
 
// ...

C'est tellement plus simple, plus rapide, plus C++, plus performant, plus sécurisé, etc., que je ne vois même pas pourquoi faire autrement !

À bientôt.

Le Farfadet Spatial

[coyotte507]

Pourquoi dans ce cas ne pas faire ainsi?

Code :

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

1
2
3
4
5
6
7
8
9
string nom;
int annee;
int quantite;
 
ifstream f("monfichier");
 
getline(f, nom);
f >> annee;
f >> quantite;

[Le Farfadet Spatial]

Salut à tous !

Pourquoi dans ce cas ne pas faire ainsi?

Code :

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

1
2
3
4
5
6
7
8
9
string nom;
int annee;
int quantite;
 
ifstream f("monfichier");
 
getline(f, nom);
f >> annee;
f >> quantite;

Tu n'es pas encore assez rapide, petit scarabée !

Sinon, tu oublies juste un champs, donc ça risque de ne pas bien se passer : il faut aussi enregistrer le label. D'autant qu'il doit sans doute l'utiliser. Cela dit, nous avons la même idée...

À bientôt.

Le Farfadet Spatial

[coyotte507]

Salut, ma variable "nom" correspond à ton label.

Ne vaut-il mieux pas utiliser getline pour le nom, dans le cas où il y a un espace?

[Le Farfadet Spatial]

Salut à tous !

Salut, ma variable "nom" correspond à ton label.

Ne vaut-il mieux pas utiliser getline pour le nom, dans le cas où il y a un espace?

Tiens, ça m'apprendra à lire en diagonale : j'avais sauté le getline...

Tu as raison et me voilà tout rouge de honte !

À bientôt.

Le Farfadet Spatial