Attention au "line ending" qui est different suivant le systeme d'exploitation (\r\n windows) et (\n) linux. Le fait est que tu ne verifie pas cette information, il y a (\r) en trop sur mon systeme qui implique une écriture éroner dans la console :
mon problème est :
je ne comprends pas ce que c'est un line ending
qu'elle sont les etapes qu'on doit suivre pour changer line ending si on travaille sur Codeblocks.
- Edité par hamzakamal123 14 novembre 2018 à 13:10:02
La gestion de fin de ligne (d'un texte) n'est pas normalisé, et cela même avant l'invention de l'informatique : dès les machines à écrire mécanique.
CR=> ramener le chariot (de la machine à écrire) en début de ligne (en descendant d'une ligne, ou pas)
LF=> descendre d'une ligne.
Quand l'informatique a voulu traiter les chaines de caractères, personne ne s'est accorder sur comment encoder un retour à la ligne.
Les uns on considérer qu'un retour à la ligne devait contenir les 2 caractères ("CR" + "LF") {CPM8=>DOS=>Windows} ; d'autres que "LF" suffisait car, pour eux, descendre d'une ligne impliquait de ramener le "chariot" en début de ligne {UNIX=>Linux}; et d'autres encore que "CR" {Les vieux OS Mac}.
Le message que tu as reçu est ambigu. Est-ce un problème dans les sources ou dans le programme générer ?
Si c'est un problème lié aux sources, les IDE modernes prennent en charge facilement ce micmac soit en s'adaptant au format utilisé par les sources, soit en convertissant automatiquement les retours à la ligne.
Si votre interlocuteur n'utilise pas d'IDE, il peut facilement utiliser des outils de conversion d'une convention d'encodage de retour à la ligne à une autre. Les outils professionnels de gestion des sources, comme Git, gèrent automatiquement ces conversions.
Si c'est donc sur les codes sources qu'est le problème, soit c'est une personne qui maitrise peu l'informatique (un peu comme vous), soit c'est un ayatollah de SA CONVENSION (ici, celle d'Unix et nouveau Mac).
Si le problème n'est pas vraiment dans le code source mais dans le programme généré, et pour le coup, il a plutôt raison, il est préférable, pour la portabilité, de ne pas utiliser directement les "\r\n" dans les chaines de caractère mais utiliser des constantes comme "std::endl", qui change de valeur en fonction de l'OS cible.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Si le problème n'est pas vraiment dans le code source mais dans le programme généré, et pour le coup, il a plutôt raison, il est préférable, pour la portabilité, de ne pas utiliser directement les "\r\n" dans les chaines de caractère mais utiliser des constantes comme "std::endl", qui change de valeur en fonction de l'OS cible.
La bibliothèque standard gère normalement très bien tout ça et tu n'as pas besoin d'utiliser \r\n, mais seulement \n. Elle s'adapte en fonction de l'OS cible.
Enfin, on pourrait sûrement mieux comprendre ton problème si tu nous postais la ligne qui génère une erreur.
La bibliothèque standard C++ est en grande partie basée sur la stdlibc. Or elle gère très bien le '\n' sans std::endl car std::endl n'existe pas dans la stdlibc.
#include <iostream>
#include <ctime>
#include <cstdlib>
#include <vector>
#include <string>
#include <fstream>
using namespace std;
string melangeLettres(string mot)
{
string melange;
int position(0);
while(mot.size()!=0)
{
position = rand() % mot.size();
melange +=mot[position];
mot.erase(position, 1);
}
return melange ;
}
int main ()
{
srand(time(0));
string motMystere,motUtilisateur, motMelange,partie,ligne,motJoueurs1,motJoueurs2;
string monfichier("dico.txt");
vector <string> mots;
string joueurs;
int i(0),j(0);
ifstream monflux (monfichier.c_str());
while(getline(monflux,ligne))
{
mots.push_back(ligne);
}
cout << "------------Mon Nouveau Jeu Mot Mystere !------------" << endl;
cout << "<<<<<------------------------------------------->>>>>" << endl << endl;
cout << "Retrouver le mot qui se cache derriere le mot Mystere"<<endl<<endl;
cout << "--------------Vous n'avez que 5 essaie---------------"<<endl<<endl;
cout << "Bonne Reponse :+5points ; Mauvaise Reponse : -5points"<<endl<<endl;
do
{
cout <<"Nombre de joueurs[1/2]"<<endl;
cin>>joueurs;
} while(joueurs != "1" && joueurs != "2");
if(joueurs == "1")
{
do
{
int essaie=5;
motMystere = mots[rand()% mots.size()];
motMelange = melangeLettres(motMystere);
do
{
cout<<endl<<"quel est le mot " <<motMelange<<endl<<endl;
cout<<"il vous reste "<<essaie<<" essaie"<<endl<<endl;
cout<<"reponse : "; cin>>motUtilisateur;
cout<<endl;
if(motUtilisateur != motMystere)
{
cout<<"ce n'est pas le mot"<<endl;
essaie--;
}
else
{
cout<<"Bravo"<<endl;
i +=5;
}
}while(motMystere!= motUtilisateur && essaie>0);
if(essaie == 0)
{
cout<<endl<<"solution : "<<motMystere<<endl;
i -=5;
}
do
{
cout<<"est ce que vous voulez faire une nouvelle partie[oui ou non]"<<endl;
cin>>partie;
}while(partie != "oui" && partie !="non" );
}while(partie == "oui");
cout<<"ton score est : "<<i<<endl;
}
else if(joueurs == "2")
{
do
{
int essaie = 5;
cout<<"le joueur 1 commence la partie"<<endl<<endl;
cout<<"saisir le mot :"<<endl;
cin>>motJoueurs1;
motMelange = melangeLettres(motJoueurs1);
for(int m(0);m<=50;m++)
{
cout<<endl;
}
cout<<"c'est le joueur 2 qui va repondre"<<endl<<endl;
do
{
cout<<endl<<"quel est le mot " <<motMelange<<endl<<endl;
cout<<"il vous reste "<<essaie<<" esaaie"<<endl<<endl;
cout<<"reponse :";cin>>motJoueurs2;
cout<<endl;
if(motJoueurs2 != motJoueurs1)
{
cout<<"ce n'est pas le mot"<<endl;
essaie--;
}
else
{
cout<<"Bravo"<<endl;
j+=5;
}
}while(motJoueurs1!= motJoueurs2 && essaie>0);
if(essaie == 0)
{
cout<<endl<<"solution : "<<motJoueurs1<<endl;
j-=5;
}
essaie = 5;
cout<<"maintenant c'est tour du joueur 2 "<<endl<<endl;
cout<<"saisir le mot :"<<endl;
cin>>motJoueurs2;
motMelange = melangeLettres(motJoueurs2);
for(int k(0);k<=50;k++)
{
cout<<endl;
}
cout<<"c'est le joueur 1 qui va repondre "<<endl<<endl;
do
{
cout<<endl<<"quel est le mot " <<motMelange<<endl<<endl;
cout<<"il vous reste "<<essaie<<" esaaie"<<endl<<endl;
cout<<"reponse :";cin>>motJoueurs1;
cout<<endl;
if(motJoueurs1 != motJoueurs2)
{
cout<<"ce n'est pas le mot"<<endl;
essaie--;
}
else
{
cout<<"Bravo"<<endl;
i+=5;
}
}while(motJoueurs2!= motJoueurs1 && essaie>0);
if(essaie == 0)
{
cout<<endl<<"solution : "<<motJoueurs2<<endl;
i-=5;
}
do
{
cout<<"est ce que vous voulez faire une nouvelle partie[oui ou non]"<<endl;
cin>>partie;
}while(partie != "oui" && partie !="non" );
}while(partie == "oui");
cout<<"score finale du joueur 1 : "<<i<<" score finale du joueur 2 : "<<j<<endl;
}
return 0;
}
>La bibliothèque standard gère normalement très bien tout ça
Oui avec "std::endl", le reste c'est de l'UB.
Je ne suis pas sûr de comprendre ce que tu veux dire. Que "\n" dans un flux est moins spécifié que endl relativement aux fins de ligne? La seule façon de reprendre le contrôle, c'est avec les ouvertures en "binaire", sinon, à un flush près, "\n" et endl, c'est la même chose.
J'ai plutôt l'impression, ici, que le correcteur est sous un système *nix et qu'on lui a fourni des sources produites sous un système windows et qu'il s'est ramassé erreurs et/ou warnings à la compilation.
Oui; effectivement; le correcteur est sous un système Unix et moi sous un systeme Windows;
qu'est ce que je dois ecrire ou faire dans le code que je viens d'envoyer là haut pour que le correcteur ne soit plus ramassé par des erreurs ou warning à la compilation
et donnez moi un exemple sous forme de code pour comprendre un peu plus et gerer ce genre de chose
- Edité par hamzakamal123 26 novembre 2018 à 12:31:56
Vu qu'il n'y a aucun \n ou \r qui traine dans ton source, je ne voit pas ce qui chagrine le correcteur.
Par contre, ce qui pique les yeux: - Using namespace std est considéré comme une mauvaise pratique: Raisons + que faire. - Ne prédéclare pas tes variables, elles ont une durée de vie inutilement longue et une portée plus grande que nécessaire. Déclare les et initialises les juste avant leur première utilisation. - rand/srand sont dépréciés en C++, la génération de nombres aléatoires se fait via les classes de l'entête <random>. - Un indice de tableau ne peux être négatif, utilise un type non signé, ou le type expressément adapté à cela: size_t. - Ta fonction main est trop longue et ne respecte pas le SRP, divise la en plusieurs fonctions avec chacune une (et une seule) responsabilité clairement définie. - Manque de constances. - Passage de paramètres par référence. - Initialise tes variables avec des accolades, ou l'operateur d'affectation. - Indentation un peut malheureuse sur la fin.
Il faudrait que tu utilises un environnement de développement qui soit "aware" quant à ces sujets là, et à ce moment-là que tu paramètres cet ED(I) pour produire des fins de fichiers "\n" à la *nix.
En général le plus simple est que le correcteur sous linux s'adapte car c'est celui qui a le plus de chances de comprendre ce qui se passe, et c'est aussi celui le mieux outillé pour rectifier le tir. Le sujet est un bon gros chouilla plus complexe pour un débutant sous Windows. D'autant qu'à mon avis vous êtes bien plus nombreux que les newbs sous Linux.
En plus, la pire situation possible consisterait à fournir un fichier en fin de ligne *nix à quelqu'un sous windows qui n'y pipe rien et qui collerait un 0 parce que justement, il n'y pipe rien -- les joies de la correction par des pairs...
Envoie ton correcteur sur ce fil. C'est malheureux, mais à moins qu'il ne soit ton unique correcteur à vie, il vaut mieux que tu restes comme tu es.
et donnez moi un exemple sous forme de code pour comprendre un peu plus et gerer ce genre de chose
Ce n'est pas réellement dans ton code, ce sont les caractères invisibles ajoutés par ton éditeur de code en fin de ligne. bacelar a très bien détaillé cela dans son premier post.
Et comme l'a dit bacelar, c'est normalement géré automatiquement par les outils de gestion du code, comme git. ( Cf par exemple ces explications sur les options de git : https://stackoverflow.com/questions/10418975/how-to-change-line-ending-settings ). Mais comme vous n'utilisez pas ces outils pour les exos (de mémoire, vous vous envoyez directement les sources dans un zip ?), il faut faire manuellement ces corrections. Je ne sais pas si C::B sait gérer cela.
Tu dois probablement pouvoir trouver des scripts qui font ça sur internet, dans le pire des cas.
(Ou mieux, a mon avis : ouvres un compte GitHub, push tes sources sur GitHub avec git, et donnes le lien du GitHub au correcteur. Il pourra corriger directement la bas s'il veut, ou télécharger tes sources dans un zip s'il préfère)
a- Vu qu'il n'y a aucun \n ou \r qui traine dans ton source, je ne voit pas ce qui chagrine le correcteur.
Par contre, ce qui pique les yeux: b- rand/srand sont dépréciés en C++, la génération de nombres aléatoires se fait via les classes de l'entête <random>. c- Un indice de tableau ne peux être négatif, utilise un type non signé, ou le type expressément adapté à cela: size_t. d- Initialise tes variables avec des accolades, ou l'operateur d'affectation. Edité par Deedolith il y a 5 minutes
Je pinaille sur ces points.
b- tu as raison.
d- on peut débattre. Je ne me force pas à employer des accolades qui n'ont d'unifiées que le nom -- cf vector(4, 42) VS vector{4,42}
b- et d- On est sur de la correction par pair débutant qui ne connaît que le tuto du sdz/oc, il ne faut pas trop en attendre sur le sujet. La remarque est potentiellement vraie dans l'absolu, mais elle est vraisemblablement hors de portée de l'OP.
a- Bien sûr que si, il y a au moins un "\n" à la fin de chaque ligne, et visiblement d'après le correcteur sous linux, il y a un "\r" à chaque fois avant. On parle d'encodage des fichiers sources, pas des éventuels littéraux C ou C++ constitués de plusieurs caractères
c- Passé un temps je le signalais aussi, maintenant j'ai cessé. Nous sommes sur les même genre de débat que celui qui opposait 0 à NULL: les détails techniques sont tels qu'il y a des désaccords entre experts. En fait, c'est limite pire, il y a plus d'un expert qui estime que l'utilisation de non signés pour les tailles est une erreur dans la norme du langage et que le mauvais choix a été fait dans le passé (Stroustrup, Stepanov, Niebler...). Le sujet n'est pas si trivial. Et du coup la raison pour lui dire d'utiliser des non signés est loin d'être la bonne. La bonne est qu'un choix a été fait à une époque dans le standard (pour les raisons que tu indiques), et que pour éviter des warnings (et potentiellement des erreurs), il vaut mieux utiliser le type 100% compatible avec les bouts de la SL qui sont utilisés.
et que pour éviter des warnings (et potentiellement des erreurs)
J'ajouterais que si on n'a pas ces warnings, c'est qu'on n'a pas activé assez d'options de compilation. Il existe des outils pour vérifier automatiquement le code (à commencer par le compilateur), il faut les utiliser si on veut améliorer la qualité de son code.
× 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.
Discord NaN. Mon site.
Discord NaN. Mon site.