tu utilises tes doigts pour taper sur les touhes du clavier, ce qui devrait écrire le code
une fois fini, tu lances la compilation (sous Visual Studio, par exemple, il faut aller dans le menu "générer")
tu essaye ton programme.
Pour le reste, c'est à toi de faire le boulot, nous, on peut au mieux te donner des pistes à suivre
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Ce ne sont pas des blagues, c'est de l'ironie. Si ils avaient voulu blaguer je pense qu'ils auraient essayé de t'aider clairement mais ils n'en voient pas l’intérêt et moi non plus. Sache qu'en programmation tu as le droit de te servir de ton cerveau et du Web.
Ton C++ est mauvais, et obsolète depuis près de 20 ans...
Petit truc, si tu as un bon éditeur. Écris des chose du genre sxcout et remplace globalement les sx par std::. C'est plus court à coder
Oui, parce qu'il faut dire ce qui est: ca prend décidément un temps bête que de devoir écrire cinq lettre
Tu n'imagines pas, je suis sur que tu perds très facilement 0.3 secondes à chaque fois que tu dois utiliser le nom pleinement qualifié d'une des fonctionnalités de la bibliothèque standard!!!
- Edité par koala01 27 juillet 2020 à 22:09:03
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Le fait est que, si l'on déconseille fortement l'usage de la directive using namespace std;ce n'est pas ** uniquement ** parce que c'est une instruction obsolète, ni pour faire joli, et encore moins pour "être conforme aux bons usages"!
C'est parce que cela permet à la personne qui écrit le code de se retrouver dans une situation qui pose problème.
Imagines trente secondes un code aussi simple que
#include <iostream>
using namespace std; // "c'est trop pratique" qu'a dit l'autre !!!
int main(){
int cout = calculerLaFacture(numeroDeFacture);
cout<<"monsieur nous doit "<<cout<<"\n";
}
Serais tu étonné si je te disais que ce code n'a aucune chance de compiler sous cette forme?
Si l'on déconseille l'utilisation de cette directive, c'est, avant tout, parce que la bibliothèque standard (et une très grosse majorité des bonnes bibliothèques C++) ont la bonne idée de ranger correctement leur fonctionnalités dans des boites, ce qui permet de les retrouver facilement et, surtout, d'éviter les conflits qui risquent immanquablement d'arriver parce que deux bibliothèques auront choisi le même nom pour désigner chacune une fonctionnalité.
Utiliser la directive using namespace revient à ... renverser ces boites sur la table (car la directive fonctionne avec n'importe quel espace de noms ).
Mais, du coup, on se retrouve "facilement" dans une situation dans laquelle nous avons sur la table deux fonctionnalités qui portent le même nom, parce qu'elles ont été fournies par des bibliothèques différentes.
Et bien sur, le compilateur n'a aucun moyen de savoir quelle fonctionnalité il doit choisir si on souhaite l'utiliser!
Il est d'ailleurs assez frustrant de se rendre compte que le seul moyen d'éviter les conflits à ce moment là, sera, justement, d'utiliser les noms pleinement qualifié, ce qui est -- justement -- ce que l'on espérait en utilisant cette directive!
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Tu as vraiment bien expliqqué la situation au-dela du nom de variable 'cout' auquel je n'aurais pas pensé et le '\n' qui n'est pas forcément supporté correctement sur toutes les machines.
Le std::endl me semble plus correct.
Le Tout est souvent plus grand que la somme de ses parties.
Tu as vraiment bien expliqqué la situation au-dela du nom de variable 'cout' auquel je n'aurais pas pensé et le '\n' qui n'est pas forcément supporté correctement sur toutes les machines.
Le std::endl me semble plus correct.
le '\n' est parfaitement supporté par l'ensemble des machines, tu peux dormir tranquile à ce sujet ;).
La seule chose, c'est que les différents systèmes d'exploitation vont -- peut-être -- traiter le '\n' différemment lorsqu'il souhaiteront l'écrire dans un fichier, certains os écrivant deux octets (CR + Lf, ou Carriage Return + Line Feed; valeur respectives 13 et 10), d'autres n'écrivant que LF(line feed; valeur 10) et d'autres encore n'utilisant que le CR (valeur 13).
Et le fait est qu'il en sera de toutes manières de même pour std::endl .
Mais je peux te rassurer: les différentes implémentations de la bibliothèque standard ont le bon gout de prendre ces particularités en charge de manière transparente
Par contre, ce qu'il faut savoir au sujet de std::endl, c'est qu'il ne fait pas que rajouter le(s) caractère(s) de fin de ligne à ton flux: il exécute également un flush du flux. C'est à dire qu'il force le flux à envoyer l'ensemble de ce qui n'a pas encore été traité vers la sortie (écriture disque pour le cas d'un std::ofstream, affichage à l'écran dans le cas de std::cout)
Quand il n'y a qu'un seul affichage, comme dans le code que je présente, cela ne va sans doute pas prêter à conséquence.
Par contre, lorsque tu as de nombreuses données à envoyer dans ton flux, le fait de le forcer à se vider à chaque fois que tu veux aller à la ligne -- alors qu'il va, de toutes manières, le faire de manière régulière -- peut considérablement nuire aux performances.
Du coup, on peut réellement se dire que les flux ont -- décidément -- été codés par des gens qui savaient ce qu'il faisaient, et que le flux sait -- a priori -- bien mieux que toi lorsqu'il doit envisager d'envoyer les données non traitées "vers la sortie", et qu'il vaut mieux le laisser s'en occuper tout seul, sans essayer d'y mettre son grain de sel
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
C'est un peu simplifié, mais, en gros, c'est à peu près cela, en effet...
C'est ce qui explique que tu aies parfois des fichiers (texte ASCII) dont le texte n'apparait pas forcément correctement quand tu les ouvres avec notepad par exemple (attention, je parle du notepad de windows, pas de notpad++ :
Pour faire simple : le système d'exploitation qui a écrit le fichier -- ou, parfois, l'application qui l'a écrit -- utilisait un format de fin de ligne différent
Par chance, il y a de plus en plus d'outils qui sont capables de gérer les différents formats de fin de ligne et de les convertir au besoin
Par exemple, les serveur git (framagit, github, ...) sont, généralement, hébergés sur des serveurs qui tournent sous linux, et qui utilisent donc seulement LF comme fin de ligne, mais le client git pour windows est capable, au moment où tu récupère un fichier à partir du serveur, de convertir automatiquement les LF en LF CR (et, inversement, de convertir les LF CR en LF lorsque tu envoies le fichier sur le serveur).
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
https://zestedesavoir.com/tutoriels/822/la-programmation-en-c-moderne/
https://zestedesavoir.com/tutoriels/822/la-programmation-en-c-moderne/
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
https://zestedesavoir.com/tutoriels/822/la-programmation-en-c-moderne/
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
En recherche d'emploi.
https://zestedesavoir.com/tutoriels/822/la-programmation-en-c-moderne/