Cherche adepte programation

[quote=“nik000, post:901401”]J’aime beaucoup le C/C++ (et d’autres) mais faut etre honnete, il y quand meme beaucoup de concepts qui peuvent dégouter à vie un débutant…[/quote]Personne a dit que débuter la programmation c’était facile^^

Le C c’est la plaie parce qu’il faut tout le temps faire nos déclarations, nos allocations mémoire et jongler avec des pointeurs.
Le C++ je trouve ça facile à prendre en main par contre et ses possibilités sont infinies.

[quote=“sixsicksix, post:901389”]yes ok parfait , c’est bien la fonction malloc() (pour l’allocation) et sizeof ( pour la taille) en c++[/quote]En fait malloc et sizeof sont des fonctions héritées du C. Si tu utilises correctement les classes du C++ tu ne devrais jamais en avoir besoin ni trop te faire chier avec des pointeurs.

Si tu utilises CFile par exemple, l’allocation mémoire va se faire toute seule et tu devrais juste avoir à faire en sorte de récupérer tes valeurs correctement et d’écrire au bon endroit dans ton fichier (ce qui peut vite devenir complexe quand on a 50 valeurs dans notre fichier).
Ça va faire plaisir à Simpson en plus parce que QT a une fonction QFile qui fonctionne presque de la même façon^^

Yes merci flibustier , oui c’est ce que j’avais cru comprendre du c++ , qu’il était “plutôt” simple et très couramment utilisé.

En tous cas c’est cool d’avoir des mec comme vous sur le forum poker , il y a de grande chance que je revienne vers vous assez vite :D.

je vais allez voir tous sa , notamment le Cfile , avec un peut de chance je comprendrais assez vite , que mes questions devienne plus intéressante pour vous ^^.

Encore une fois merci All !

Merci , sa pourra probablement me sauvé la vie quand vraiment je galèrerais ^^

sur ce , c’est bientot la session , Gl all.

a très bientôt surement :laugh:

Yop all , je revient avec une question cette fois,toujours en c++, j’ai constaté un fait étrange en essayant de faire un programme capable de lire un fichier texte et de comparé chaque mot a un mot clé que j’ai rentrer au préalable et donc capable de me dire si le mot cherché est dans le fichier texte.

Le principe est simple :

-il lit le fichier mot par mot grâce a une boucle while

-A l’interieur de la boucle while , il fait un test avec If (motchercher == Mot du moment lu par la boucle)

-si oui il rajoute 1 a un int ( qui comptabilise le nombre de mot trouvé )

-il sort du test et ajoute 1 a un autre int ( qui lui comptabilise tous les mot , puisque placé en fin de boucle)

Si je laisse le programme comme sa , il marche tres bien et il n’y a pas de soucis.

Mais si je décide de lui demandé a l’intérieur de la boucle , ou est la position du curseur (en terme d’octet) dans le fichier grace a la fonction : tellg()
qui est censé simplement me retourné un int qui est la positions du curseur , il déréglè completement la boucle et m’indique un nombre de mot différent de la réalité.

Même une fonction qui demande au curseur de resté a sa place , grace a : seekg(0,ios::cur)
déréglè completement la boucle.

les symptomes sont : -ne commence a “bug” que si il y a beaucoup de mot.
-Changement du nombre de mot contenu dans le fichier
-Changement d’emplacement ou sont censé se trouvé les mot clé (les unités sont le “mot” type le mot clé se trouve apres le Niem mot )
-fait bizarre , donne le bon nombre de mot clé.

j’aimerais savoir , si quelqu’un a une idée de pourquoi ces fonction sont capable de changer la lecture de la boucle ?

Je débute aussi la programmation, et même pas en C++, mais en c moi >.> faut croire que je suis taré… enfin en fait je savais pas que c’était le pire langage à apprendre avant de lire ce thread lol… Bref

Donc mon avis est à prendre avec des pinces monseigneur hein mais

Je pense que c’est parce que la fonction que tu utilises déplace le curseur. Du coup t’es plus au même endroit quand l’autre fonction reprend la main et ça fout la merde.
Genre, si tu fais fgetc(), ça te lit le caractère en cours. Mais en fait ça fait pas que ça.
Exemple : t’as le mot “Poker” dans ton ficher.
fgetc(); -> P
fgetc(); -> o
etc

Du coup, sans doute que tellg() fait pareil.
Tu fais tellg(); tellg(); les 2 fois ça te donne la même position?

[quote=“WaitWaitW, post:905926”]Je débute aussi la programmation, et même pas en C++, mais en c moi >.> faut croire que je suis taré… enfin en fait je savais pas que c’était le pire langage à apprendre avant de lire ce thread lol… Bref

Donc mon avis est à prendre avec des pinces monseigneur hein mais

Je pense que c’est parce que la fonction que tu utilises déplace le curseur. Du coup t’es plus au même endroit quand l’autre fonction reprend la main et ça fout la merde.
Genre, si tu fais fgetc(), ça te lit le caractère en cours. Mais en fait ça fait pas que ça.
Exemple : t’as le mot “Poker” dans ton ficher.
fgetc(); -> P
fgetc(); -> o
etc

Du coup, sans doute que tellg() fait pareil.
Tu fais tellg(); tellg(); les 2 fois ça te donne la même position?[/quote]

Sa me semble effectivement être quelques choses du style.

Sinon tu veut que je test de regarder 2 fois d’affilé ma position voir si elle change entre temps ?

[quote=“sixsicksix, post:905927”][quote=“WaitWaitW, post:905926”]Je débute aussi la programmation, et même pas en C++, mais en c moi >.> faut croire que je suis taré… enfin en fait je savais pas que c’était le pire langage à apprendre avant de lire ce thread lol… Bref

Donc mon avis est à prendre avec des pinces monseigneur hein mais

Je pense que c’est parce que la fonction que tu utilises déplace le curseur. Du coup t’es plus au même endroit quand l’autre fonction reprend la main et ça fout la merde.
Genre, si tu fais fgetc(), ça te lit le caractère en cours. Mais en fait ça fait pas que ça.
Exemple : t’as le mot “Poker” dans ton ficher.
fgetc(); -> P
fgetc(); -> o
etc

Du coup, sans doute que tellg() fait pareil.
Tu fais tellg(); tellg(); les 2 fois ça te donne la même position?[/quote]

Sa me semble effectivement être quelques choses du style.

Sinon tu veut que je test de regarder 2 fois d’affilé ma position voir si elle change entre temps ?[/quote]

Exactement :p. Si jamais en lisant la position ta fonction déplace le curseur c’est là qu’est ton problème. Auquel cas, quand tu lis la position, tu ramènes le curseur 1 case en arrière et le tour est joué :slight_smile:

Sa valait le coup de tenter mais non a priori la positions est la même , le pire c’est que j’ai reussi a avoir une constante de 2 mot en moins lorsque j’insert tellg() , alors qu’il y a 10 mot clé , en gros il semble que les mots oubliée ne sont pas les mots clé.Mais pourquoi 2 alors qu’il passe théoriquement 10 fois dans le test , et donc par la fonction … sa defi la logique ^^

Mais clairement sa vient du faite que je l’utilise dans la boucle , si je le place hors de la boucle il y a pas de soucis et tous marche.

Du coup , en plus de pas comprendre le comportement du programme quand j’insert tellg.Je peut pas connaitre la positions du mot chercher puisqu’il sortira de la boucle a la fin du fichier texte.

Je suppose que je peut trouvé d’autre façon de le savoir , mais sa complique beaucoup du coup j’imagine qu’il y a quand même un moyen de le faire comme sa.

si quelqu’un a une idée je suis preneur , surtout pour comprendre le comportement qu’induis la fonction tellg() , ou seekg() si on l’insert a l’intérieur de la boucle while.

bon du coup j’ai trouver une réponse sur internet , a moitié satisfaisante , mon probleme est résolue mais j’ai toujours pas compris le pourquoi du comment.

Il suffisait (a priori) que je rajoute quand j’ouvre mon fichier :

ifstream(“Texte.txt”,ios_base::binary);

Si certain peuvent m’expliquer ce que fait ios_base::binary et pourquoi cela règle mon problème sa m’aiderais beaucoup pour continuer.

Je suis malheureusement bien rouillé en programmation mais je me rappelle avoir eu des problèmes similaires.
La fonction ifstream permet de formater un flux destiné à la lecture (ofstream pour un flux d’écriture). Basiquement je crois qu’elles permettent de renseigner les autres fonctions de la classe sur la nature du flux afin d’optimiser les opérations.

Là où c’est très curieux c’est que si on manipule une chaîne de texte on ne devrait pas avoir besoin de la formater en binaire puisque le « mode chaîne de caractères » et celui par défaut.

Comme je le disais au début, j’ai déjà eu ce problème et pas seulement en C++ et je n’ai pas de réponses sur le pourquoi du comment.
J’ai quand même quelques hypothèses :

  1. il y a un bug dans une des fonctions de stdlib (toutes les classes objet de lecture/écriture font appel aux fonctions de stdlib) qui traite normalement les flux comme du texte par défaut et qui pour une raison inconnue se met subitement à traiter les infos dans un autre format par défaut. S’il y a problème de conversion a un moment donné ça expliquerait certains résultats curieux.
  2. il pourrait s’agir d’un problème matériel. Les processeurs qu’on utilisent aujourd’hui sont très rapides et performants mais il n’en reste pas moins qu’ils sont toujours incapable de traiter une infinité de décimales. Ça peut paraitre étonnant en 2016 mais nos processeurs, même haut de gamme, sont toujours capables de faire des erreurs de calculs sur des multitudes d’opérations très complexes. Le mode de calcul binaire et hexadécimal font parti du fonctionnement le plus bas niveau du processeur et peut-être que c’est ce qui explique pourquoi il fait moins d’erreurs en opérant dans ce format plutôt qu’en traitant les infos en tant que chaînes de caractères (à bas niveau les chaînes vont quand même finir par être converties en binaire).
  3. il est possible aussi que ça vienne juste d’un « conflit » avec les définitions windows ou d’un autre programme. Tous les processus ouvert réalisent tout un tas d’opérations en arrière plan et ils passent leur temps à « forcer » le type des informations qu’ils traitent. Le système d’exploitation et les autres programmes utilisent des typedef propres à leur méthode d’énumération du style : #define text 1 - #define binary 2 - etc
    Il est possible que certaines de ces définitions soient identiques à celles de la classe ios_base et soient « confondues » (je sais pas si c’est vraiment possible à vrai dire mais si je ne sais pas je n’exclue rien).
  4. il est fortement possible aussi que le système fasse des opérations de maintenance sur les flux ouverts pour des raisons de sécurité et d’optimisation. Si durant une de ces opérations Windows ou l’antivirus formate le flux ouvert alors ça expliquerait les incohérences. Par formatage j’entends le fait d’accéder au flux de tel ou telle façon, en faisant cela on modifie la façon dont le processeur va traiter le flux dans les opérations futures. Encore une fois j’en sais rien mais ça reste une possibilité.

Bref je ne sais pas vraiment à quoi c’est dû et je ne peux que faire des suppositions. Le fait est que les opérations de lecture marchent souvent mieux en mode binaire dans la plupart des langages. En programmation des fois il vaut mieux ne pas trop se poser de questions et se contenter de faire ce qui marche^^ En soit c’est un conseil assez affreux parce que c’est à cause de cette logique et des impératifs de temps de production que les éditeurs de software continuent de nous pondre des logiciels bourrés de bugs mais bon…

Cela dit le fait de formater ton flux en binaire va de toute façon accélérer les opérations de lecture surtout si tu en fais beaucoup dans ta boucle donc ça n’est pas non plus juste une question de corriger un bug incompréhensible.
[b]
Perso je fais généralement ça comme ça :

  • J’ouvre et j’initialise le flux de lecture en mode binaire. Je parcours ensuite le flux dans une boucle while.
  • Je copie le flux dans un buffer texte (que je formate au passage) et je crée une 2ème boucle for à l’intérieur de la première pour parcourir mon buffer et extraire les infos que je veux.
  • Je ferme le flux principal à la sortie de ma boucle while.
    De cette façon j’ai 2 buffers, un qui se focalise que sur les données brutes en mode binaire et que je ne touche jamais sauf pour copier ce qu’il y a dedans et un 2ème au format char ou string que je peux triturer dans tous les sens sans risquer de d’endommager mon buffer de flux principal qui, comme tu l’as vu, subit déjà plein de modifications à chaque accès. Ça permet aussi de clarifier un peu le code, dans la boucle while on réalise les opérations de lecture/écriture/déplacement de pointeur et dans la 2ème boucle j’ai toutes mes opérations de traitements de chaînes de caractères.
    La seule problématique avec cette méthode c’est de s’assurer qu’on a pensé à toutes les conditions de sortie de la 2ème boucle, autrement on risque de se retrouver coincer dans une boucle infinie.[/b]
    Petite astuce : parfois on a besoin de sortir des deux boucles à la fois, ce sera par exemple le cas si tu utilises un marqueur de fin de fichier dans ton .ini, .txt, etc. Si on atteint le marqueur on a aucune envie de continuer à lire le fichier puisqu’on sait qu’on est arrivé à la fin. En cas d’erreur dans les valeurs qu’on récupère on peut vouloir aussi tout arrêter pour afficher un message d’erreur.
    Pour sortir des 2 boucles à la fois j’utilise tout bêtement la fonction « break; », la même qu’on utilise habituellement dans les switch{ case : … }

J’espère que ça t’aidera un peu.

Deja grand merci flibustier.oui ca m’aide beaucoup,surtout pour entrevoir la façon de raisonné et c’est probablement le plus important.

j’ai trouver un résumé du problème sur internet , peut etre tu comprendra mieux :

" Sous Windows, vous pouvez être surpris de lire un peu moins de caractères dans un fichier texte, ou d’en avoir écris plus que ce que vous avez demandé. Vous constatez cela en comparant la taille de votre flux (ou la taille théorique de ce que vous avez écris) avec la taille réelle du fichier indiquée par Windows. Si votre programme n’est pas en cause, alors l’explication est simple : il s’agit du traitement particulier opéré par ofstream et ifstream lorsqu’ils travaillent sur des fichiers ouverts en mode texte, ce qui est le cas par défaut.
Ceci n’a généralement pas d’influence, sauf sous DOS et Windows où un saut de ligne est matérialisé par la séquence des deux caractères ‘\r’ et ‘\n’. Pour assurer une meilleure portabilité du code, le langage C++ (ainsi que le langage C) considère qu’une fin de ligne est identifiée par un unique caractère ‘\n’.
Pour cette raison, en mode texte sous Windows, l’objet ifstream va ignorer le caractère ‘\r’ lorsqu’il rencontre une fin de ligne, et ofstream va insérer un ‘\r’ avant chaque ‘\n’ qu’on lui a demandé d’écrire.
Ainsi, le fait que le fichier sur disque contiennent des caractère ‘\r’ que vous n’avez pas lu / écris devrait expliquer votre différence de taille constatée. Pour lire ces caractères / ne pas générer leur écriture, il faut travailler en mode binaire en spécifiant le flag std::ios_base::binary. "

Je sais pas exactement ce que sont les caractères /r et /n.

Sinon pour le programe, j’ai l’impression effectivement de faire la même chose a l’exception que je ne sais pas ce que c’est qu’un buffer ?

et une derniere question au passage ^^ , ils disent sur le site ou j’ai trouver l’explication , que les gestion de donnée en mode binaire ne sont pas portable , ils entendent quoi par la ?

En tous cas merci beaucoup flibustier.

[quote=“sixsicksix, post:906227”]Je sais pas exactement ce que sont les caractères /r et /n.

Sinon pour le programe, j’ai l’impression effectivement de faire la même chose a l’exception que je ne sais pas ce que c’est qu’un buffer ?

et une derniere question au passage ^^ , ils disent sur le site ou j’ai trouver l’explication , que les gestion de donnée en mode binaire ne sont pas portable , ils entendent quoi par la ?[/quote]/r et /n sont des caractères de saut de ligne, ils sont interprété par un programme comme un seul caractère chacun, caractère qui correspond au fait de passer à la ligne d’après. Concrètement ils font la même chose, ‘/n’ indique qu’il faut sauter une ligne et ‘/r’ est plus un saut de paragraphe si je ne dis pas de bêtise. Le ‘/r’ ne sert que pour un flux de texte “amélioré” comme ce qu’on trouve avec du rich text ou sous Word, la seule fois où je m’en suis servi c’était pour un programme d’édition de texte qui gèrait la pagination, les tabulations, etc.

En gros si tu demandes à ton programme de t’afficher une chaîne de texte (dans une messageBox, une fenêtre de texte ou dans la console), si dans ta chaîne tu as “ligne1 ligne2” ça va apparaître tel quel. Si par contre tu as “ligne1/nligne2 ligne 3” ça va apparaître comme ça :
ligne1
ligne2 ligne 3
Je te conseille de n’utiliser que le /n dans la mesure du possible puisque le /r s’utilise plutôt en combinaison avec le /n pour indiquer qu’on a pas fait que changer de ligne mais aussi de section/paragraphe.

Sinon buffer = tampon en programmation, j’ai juste l’habitude d’appeler ça comme ça mais c’est la même chose. C’est aussi une habitude de développeur que de toujours utiliser dans le code les mots qui ont le moins de lettre tout en restant compréhensible. Généralement on écrit buf1,buf2=… pour gagner du temps^^

Aucune idée sur la question de la portabilité d’une chaîne binaire, je pige pas bien parce que j’aurai eu tendance à penser que ça devrait être l’inverse justement. Quand on parle de portabilité (ou “portage”) c’est généralement dans la cadre de la compatibilité d’un programme sur plusieurs systèmes différents. Si tu développes un programme qui marche sous Windows et que tu veux qu’il marche aussi sur Android par exemple, tu vas devoir faire des modifs pour le rendre compatible avec ce système et on dit que tu “portes” ton code existant sur android.
Là où je pige pas, c’est pourquoi ça devrait pauser des problèmes, un flux binaire devrait être identique quel que soit le système. A moins que ce soit en rapport avec le fait que certains systèmes ne sont pas compatible dans tous les langages existants et qu’on peut se retrouver tout simplement sans possibilité de convertir le flux en binaire. Je vois que ça parce qu’en soit ça ne devrait pas poser de problème de portabilité, pas plus que l’utilisation de chaînes de texte brutes et sans formatage.

En tout cas cette histoire de ‘/r’ est une explication qui me satisfait bien, j’avais également constaté que windows passe son temps à nous rajouter des ‘/r’ partout et que quand il voit un saut de ligne il remplace “ligne1\nligne2” par “ligne1\n\rligne2” ce qui fout forcément le dawa derrière^^ Mais bon c’est Windows, on a l’habitude :stuck_out_tongue:

[quote=“flibustier, post:906467”][quote=“sixsicksix, post:906227”]Je sais pas exactement ce que sont les caractères /r et /n.

Sinon pour le programe, j’ai l’impression effectivement de faire la même chose a l’exception que je ne sais pas ce que c’est qu’un buffer ?

et une derniere question au passage ^^ , ils disent sur le site ou j’ai trouver l’explication , que les gestion de donnée en mode binaire ne sont pas portable , ils entendent quoi par la ?[/quote]/r et /n sont des caractères de saut de ligne, ils sont interprété par un programme comme un seul caractère chacun, caractère qui correspond au fait de passer à la ligne d’après. Concrètement ils font la même chose, ‘/n’ indique qu’il faut sauter une ligne et ‘/r’ est plus un saut de paragraphe si je ne dis pas de bêtise. Le ‘/r’ ne sert que pour un flux de texte “amélioré” comme ce qu’on trouve avec du rich text ou sous Word, la seule fois où je m’en suis servi c’était pour un programme d’édition de texte qui gèrait la pagination, les tabulations, etc.

En gros si tu demandes à ton programme de t’afficher une chaîne de texte (dans une messageBox, une fenêtre de texte ou dans la console), si dans ta chaîne tu as “ligne1 ligne2” ça va apparaître tel quel. Si par contre tu as “ligne1/nligne2 ligne 3” ça va apparaître comme ça :
ligne1
ligne2 ligne 3
Je te conseille de n’utiliser que le /n dans la mesure du possible puisque le /r s’utilise plutôt en combinaison avec le /n pour indiquer qu’on a pas fait que changer de ligne mais aussi de section/paragraphe.

Sinon buffer = tampon en programmation, j’ai juste l’habitude d’appeler ça comme ça mais c’est la même chose. C’est aussi une habitude de développeur que de toujours utiliser dans le code les mots qui ont le moins de lettre tout en restant compréhensible. Généralement on écrit buf1,buf2=… pour gagner du temps^^

Aucune idée sur la question de la portabilité d’une chaîne binaire, je pige pas bien parce que j’aurai eu tendance à penser que ça devrait être l’inverse justement. Quand on parle de portabilité (ou “portage”) c’est généralement dans la cadre de la compatibilité d’un programme sur plusieurs systèmes différents. Si tu développes un programme qui marche sous Windows et que tu veux qu’il marche aussi sur Android par exemple, tu vas devoir faire des modifs pour le rendre compatible avec ce système et on dit que tu “portes” ton code existant sur android.
Là où je pige pas, c’est pourquoi ça devrait pauser des problèmes, un flux binaire devrait être identique quel que soit le système. A moins que ce soit en rapport avec le fait que certains systèmes ne sont pas compatible dans tous les langages existants et qu’on peut se retrouver tout simplement sans possibilité de convertir le flux en binaire. Je vois que ça parce qu’en soit ça ne devrait pas poser de problème de portabilité, pas plus que l’utilisation de chaînes de texte brutes et sans formatage.

En tout cas cette histoire de ‘/r’ est une explication qui me satisfait bien, j’avais également constaté que windows passe son temps à nous rajouter des ‘/r’ partout et que quand il voit un saut de ligne il remplace “ligne1\nligne2” par “ligne1\n\rligne2” ce qui fout forcément le dawa derrière^^ Mais bon c’est Windows, on a l’habitude :P[/quote]

Yes comme d’hab merci beaucoup flibustier , c’est juste niquel.

je te dit a bientôt :whistle:

Pas de soucis, j’ai du temps en ce moment.
Va falloir bosser maintenant :stuck_out_tongue: C’est surtout par la pratique qu’on apprend, GL !