« Discussion:Programmation C++/Les types de base et les déclarations/Exercices » : différence entre les versions
Contenu supprimé Contenu ajouté
→précisions et erreurs : nouvelle section |
|||
Ligne 92 :
</source>
merci au redacteur du book pour les cour de c++ ce mieu que les livre du commerce
== précisions et erreurs ==
Section "Le type int"
"Le nombre de bits et le système de représentation des données n'est pas déterminée en C++"
C'est pour ça que, personnellement, j'encourage l'usage des types "short", "long" et "long long" (ce dernier à été ajouté dans C++11).
Pour avoir encore moins d'ambiguïtés, il y a aussi les types du header (standard du C99, également présent en C++) stdint.h.
Les types inclus dans stdint.h donnent des garanties en terme de nombre de bits avec plusieurs jeux de types: les types à nombre de bits fixe, ceux qui sont optimisés pour la vitesse sur l'architecture de la machine du compilateur, ceux qui contiennent au moins N bits... des outils bien pratiques, et indispensables quand on programme de façon portable.
A noter cela dis que le compilateur de visual studio ne respecte pas la norme C99 aux dernières nouvelles (sans vouloir faire le troll... c'est toujours la même boîte qui fout la merde) mais il n'empêche qu'il s'agit bel et bien de code standard: https://fr.wikipedia.org/wiki/Bibliothèque_standard_du_C#Normes_ANSI_et_ISO
Section "Exemple 2 : incrémentation d'une variable"
"A la place de a=a+1; , on peut également écrire a++;."
Il serait plus approprié de parler de l'autre opérateur d'incrémentation: ++a
Pourquoi? Parce que si en C la seule différence entre les deux est la priorité, en C++ il y a une différence de performance quand on utilise pas les types natifs (int, float, char, double...).
Cette différence de performance est due au fait que dans le cas de a++ on appelle le constructeur par copie de l'objet a avant de l'incrémenter. ++a n'a pas ce problème.
Certes, ça n'a d'influence que pour les types utilisateurs, mais il faut mieux prendre le réflexe le plus tôt possible: tôt ou tard, un dev c++ utiliseras les itérateurs, et si il utilise it++, il aura une perte de performance.
Donc, autant donner les bons réflexes dès le début.
Section "Différentes opérations"
Je pense qu'il serait approprié de citer également les opérateurs de type += -= .
Section "Le type double"
"Chaque opération peut être entachée "
Chaque opération EST entachée. L'erreur à toujours lieu, voila pourquoi il n'est pas trop recommandé au fil du net d'utiliser l'opérateur == sur des flottants.
Section "Compatibilité int-double"
"a=(int)b;"
Non!!! Surtout pas de cast C-style!
Avec ce cast on pourrait aussi écrire un truc comme ceci:
<source lang=cpp>
int a;
float *b;
a=(int)b;
</source>
Le compilateur ne bronchera pas forcément! Il faut mieux utiliser "static_cast<int>(b)" qui n'a aucune influence sur les performance d'exécution mais qui ne peut être contourné.
Un autre exemple de dangerosité du cast C:
<source lang=cpp>
int a;
void *b=&std::cout;
a=*(int*)b;
</source>
J'espère avoir été convainquant avec ce dernier exemple.
Sauf si c'est un cours sur le C, ce genre de cast est à '''''bannir'''''.
Donc, merci de corriger également "Exemple 8 : mettre un double dans un int"
Section "Exemple 7 : mettre un int dans un double"
"On met la valeur de a dans la variable b : cette opération s'effectue sans cast."
FAUX!
Il y a un cast implicite. C'est d'ailleurs un des dangers du C et du C++, qui font que ces langages sont dits à typage faible d'ailleurs. Typés, oui, mais pas trop. Un langage fortement typé interdirait un cast implicite de ce genre (et vu comment ça peut être pénible de résoudre certains bugs liés à ça, ce ne serait pas plus mal que les cast implicite deviennent non standards... ce qui n'arrivera sûrement jamais).
[[Utilisateur:Bmorel|Bmorel]] ([[Discussion utilisateur:Bmorel|discussion]]) 11 octobre 2012 à 14:09 (CEST)
| |||