j'apprends à utiliser QT et je rencontre en ce moment un problème. J'aimerais extraire uniquement les cinq dernière lignes d'un fichier texte.
J'ai réussis à écrire dedans et le lire en entier mais je ne trouve pas comment lire seulement les cinq dernières lignes, est ce que quelqu'un serait me donner un coup de main ?
bah! pour te répondre, tu dois avoir une variable qui stockera le N lignes de ton fichier puis dans une boucle(au niveau du teste logique) tu diras au monsieur(compilo), dès que tu arrive à la N ième ligne -5 c'est alors que tu commencera à lire.
Nota: C'est quoi le but en fait de ton projet ?, perso je ne trouve pas d'importance de lire juste les 5 dernières lignes du fichier.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
En fait, le plus facile est toujours de lire l'intégralité du fichier, de charger l'ensemble des données qu'il contient dans une collection quelconque, puis de sélectionner celles qui t'intéressent...
Car, à moins que tu n'aie la certitude que ton fichier fera toujours le même nombre de lignes, tu n'a absolument aucun moyen de savoir si tu dois prendre les lignes 16 à 20 (incluse) ou les lignes 158 à 163 (incluse)
Après, tu peux toujours envisager d'utiliser une collection particulière, que tu "configureras" de manière à ne garder que les XXX dernières lignes lues, mais ca, ce n'est plus que du détail
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
Nota: C'est quoi le but en fait de ton projet ?, perso je ne trouve pas d'importance de lire juste les 5 dernières lignes du fichier.
Effectivement ce n'est peut être pas la bonne solution, en faite j'aimerais afficher dans un QTextEdit une sorte de log des actions qu'effectuerais l'utilisateur sur la fenêtre ou il se trouve. Et je voudrais qu'on trouve dans le QTextEdit uniquement les cinq dernières actions (donc cinq lignes). J'ai pensé a mettre dans un fichiers puis en lire que les cinq dernières lignes mais je me complique peut être la vie étant donné que je débute j'ai encore du mal a trouver la solution la plus efficace pour coder ce que je veux !
koala01 désolé pour la question qui est peut être bête mais qu'appelle tu une collection ? c'est un tableau ?
Un tableau, une pile, une file, une liste... y en a plusieurs sortes adaptées à différents besoins
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
Effectivement ce n'est peut être pas la bonne solution, en faite j'aimerais afficher dans un QTextEdit une sorte de log des actions qu'effectuerais l'utilisateur sur la fenêtre ou il se trouve. Et je voudrais qu'on trouve dans le QTextEdit uniquement les cinq dernières actions (donc cinq lignes). J'ai pensé a mettre dans un fichiers puis en lire que les cinq dernières lignes mais je me complique peut être la vie étant donné que je débute j'ai encore du mal a trouver la solution la plus efficace pour coder ce que je veux !
l'une de meilleur solution est d'utilisé un conteneur à taille dynamique, perso je te conseil un std::vector mais un vector des std::string,
std::vector<std::string> tabAction;
un std::string représentera une action faite par l'utilisateur.
Pour lire par exemple les 5 dernières actions faites par l'utilisateur, tu auras :
std::vector<std::string> tabActions;
tabAction.isert(action)// sachant qu'ici action est un std::string
int taille = tabActions.size();
for(int j{taille - 5}; j < tabActions.size(); ++j){
std::cout<<tabActions[j]<<" " <<std::endl;
}
Nota: je préfère utiliser ici le code en standard C++ et non directement en Qt, désolé mais c'est pour te pousser à travaillé car tu peux le faire.
puis je te conseil de maîtriser d'abord le C++ avant de passé à Qt(sois pas pressé).
- Edité par EL-jos 21 avril 2018 à 20:36:52
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Oui mais tout dépend d'une personne(développeur) à une autre .
on dit que le goût et le couleur ne se discute pas
Pour certains truc, tu as tout à fait raison... Mais pas lorsqu'il s'agit de s'adresser au compilateur
D'ailleurs, c'est bien simple, en compilant ton programme avec les bonnes options (-Wall pour Gcc), tu obtiendrais un avertissement proche de
attention : comparaison entre des expressions entières signée et non signée [-Wsign-compare]
for(int i=0;i<tab.size();++i){
Rajoute une petite option de compilation pour te forcer à corriger l'ensemble des avertissement ( -Werror pour Gcc), et cela devient une erreur de compilation:
erreur : comparaison entre des expressions entières signée et non signée [-Werror=sign-compare]
for(int i=0;i<tab.size();++i){
~^~~~~~~~~~~
cc1plus : tous les avertissements sont traités comme des erreurs
Or, le compilateur est encore notre meilleur ami sur ce coup là, car il est capable de détecter des problèmes dont tu n'a sans doute même pas conscience...
C'est la raison pour laquelle on insiste généralement pour que la compilation s'effectue avec le plus haut niveau d'avertissement possible et, surtout, pour que chaque avertissement occasionne une correction du code de manière à résoudre le problème indiqué.
Dans 99.99.....% des cas, tu peux t'attendre à ne pas avoir de problème en ignorant un avertissement. Mais il suffit de tomber sur le pauvre malheureux cas perdu dans la masse qui posera réellement problème pour que ton application parte en couille
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
Il y a très peu de choix basé sur "les goûts et les couleurs" en programmation. Ce n'est pas de l'art. Généralement, ceux qui ne peuvent pas justifier leur choix par des raisons techniques, c'est qu'ils ne maîtrisent pas assez leurs outils.
EDIT : pour etre bien clair, voici un code très simple qui compare un nombre signé et un nombre non signé. (il n'est pas de moi)
#include <iostream>
int main ()
{
signed int a { -1 };
unsigned int b { 1 };
if (a < b)
std::cout << "a < b" << std::endl;
else
std::cout << "a > b" << std::endl;
}
Pas besoin de préciser que cela ne donne pas du tout le résultat attendu...
Koala01, bah! oui j'avais vue cette avertissement et je le savais du point où la méthode size() revoie un entier non signée donc un unsigned int
mais si je l'avais négligé c'est juste par ce que je ne voulais pas le faire (sa me prends quelque seconde à taper sur mon clavier).
gbdivers a écrit:
Il y a très peu de choix basé sur "les goûts et les couleurs" en programmation. Ce n'est pas de l'art. Généralement, ceux qui ne peuvent pas justifier leur choix par des raisons techniques, c'est qu'ils ne maîtrisent pas assez leurs outils.
tu as raison à 45% car pour moi une application ou voir même un code, je le concidère comme étant de l'art, comment?
R/ en faisant de mise à jour de mon code ou de appli et surtout de le changer de forme(en gardant toujours le même fond); tout ça pour que soit beau à voir .
bah! il faut aussi noter que j'aime l'art.
Nota: il n'y a qu'uen machine qui répète les même instructions par contre l'homme est amené à modifier, à ajouter, ...
- Edité par EL-jos 22 avril 2018 à 0:09:59
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Tu peux trouver qu'un immeuble, c'est de l'art. Mais si tu ne veux pas qu'il s'écroule et tue plusieurs centaines de personnes, tu as intérêt à faire tes choix techniques sur d'autres critères que l'art.
Si tu arrives a expliquer le résultat du code que j'ai donné (c'est à dire si tu maîtrises la technique), je m'incline et te laisserais faire de l'art. Sinon, je te dirais de l'art ne sert que d'excuse pour masquer l'ignorance.
EDIT : pour ceux qui lisent et qui pourrait trouver que mon message est un peu méprisant quand je parle d'ignorance. Les règles du C++ qui s'appliquent dans ce cas sont très peu connues. J'ai posé la question sur le discord et plusieurs personnes expérimentés en C++ se sont trompé. Moi même j'ai fait l'erreur la première fois que j'ai vu ce code et je ne savais pas expliquer pourquoi on avait ce résultat.
Fondamentalement, on est tous ignorant. Personne ne maîtrise totalement le C++.
Par contre, justifier les choses par un choix personnel, les goûts et les couleurs ou l'art, c'est une bonne méthode pour ne pas progresser. (Et c'est valable pour tous les domaines, pas que le C++)
Le compilateur interprète un code en fonction des règles de la norme C++. Manifestement, tu ne sais pas pourquoi le code est interprété de cette facon (conversion signed vers unsigned) et pas autrement (unsigned vers signed). Dit autrement, pourquoi le code est interprété comme ca :
if (static_cast<unsigned int>(a) < b)
et pas :
if (a < static_cast<signed int>(b))
Tu justifies le choix signed vs unsigned par "des goûts et couleurs", mais c'est juste parce que tu ne connais pas les règles du C++ qui s'appliquent dans ce cas là.
En fait, c'est un des nombreux paragraphe de la clause 5:
(11.5.1) If both operands have the same type, no further conversion is needed.
(11.5.2) Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank.
(11.5.3) Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type.
(11.5.4)Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type.
(11.5.5) Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
Et, bien sur, les conversion rank sont définis dans la norme (dans la clause 4.15):
(1) Every integer type has an integer conversion rank defined as follows
(1.1)No two signed integer types other than char and signed char (if char is signed) shall have the same rank, even if they have the same representation.
(1.2)The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller size
(1.3) The rank of long long int shall be greater than the rank of long int , which shall be greater than the rank of int , which shall be greater than the rank of short int, which shall be greater than the rank ofsigned char
(1.4)The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
(1.5)The rank of any standard integer type shall be greater than the rank of any extended integer type with the same size./p>
(1.6)The rank of char shall equal the rank of signed char and unsigned char
(1.7)The rank of bool shall be less than the rank of all other standard integer types.
(1.8)The ranks of char16_t,char32_t, and wchar_t shall equal the ranks of their underlying types (3.9.1)
(1.9)The rank of any extended signed integer type relative to another extended signed integer type with the same size is implementation-defined, but still subject to the other rules for determining the integer conversion rank
Dans le cas présent, c'est le §1.4 qui entre en jeu
Notes d'ailleurs que, après avoir observé le comportement du code de gbdivers, un code proche de
#include <iostream>
int main ()
{
signed int a { -1 };
unsigned short b { 1 };
if (a < b)
std::cout << "a < b" << std::endl;
else
std::cout << "a > b" << std::endl;
}
pourrait occasionner quelques surprises en vertu du §1.3
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
Oui, c'est complètement contre intuitif. En particulier à cause du rôle important de "int" dans la norme pour les promotions, on s'attend a ce que le signed soit préféré. (Et je n'ai aucune idée de pourquoi le comité à fait un choix différent).
Un autre exemple :
#include <iostream>
int main()
{
signed int a{ -1 };
unsigned int b{ 1 };
auto c = a - b;
std::cout << c << std::endl;
}
Tout cela est dans la norme et dans cppreference. En général, les devs savent qu'il existe des règles de conversion implicites (qui sont déjà un gros pavé prise de tête) : http://en.cppreference.com/w/cpp/language/implicit_conversion. Ces règles interviennent en particulier dans la résolution des appels de fonctions, et les devs un peu expérimentés savent qu'on a des choses un peu prise de tête aussi pour ca (les bool...). Sans forcément connaître les détails (probablement que la différence entre "promotion numérique" et "conversion numérique" est moins connus)
Il n'est pas nécessaire de connaître par coeur ces règles, mais c'est intéressant de lire au moins une fois les pages sur cppreference, pour savoir que cela existe. Et pouvoir les retrouver. (Et on peut ajouter la lecture des pages sur la résolution des noms, qui est aussi un sujet... "amusant" : http://en.cppreference.com/w/cpp/language/lookup )
Je vous avouerais que j'ai un peu de mal à comprendre toute la discussion, ces notions m'ont pas l'air très pour quelqu'un qui débute .
Je vais opter pour la technique du std::vector, si j'ai bien compris il faudrait que la variable qui stocke la taille du tableau sois un unsigned int car size en est un aussi.
Ce que je n'ai pas compris c'est, est-ce que dans le cas du code qu'a proposer EL-jos au début du sujet cela pose un problème de ne pas mettre un int unsigned ou cela n'aurait pas d'importance dans ce cas la mais pourrait en avoir une dans un autre cas ?
Au final, la seule chose que tu as a retenir de notre conversation, c'est la recommandation :
> ne pas mélanger des signed et unsigned
Les restes, c'est du détails techniques.
Léo_c a écrit:
Je vais opter pour la technique du std::vector, si j'ai bien compris il faudrait que la variable qui stocke la taille du tableau sois un unsigned int car size en est un aussi.
Oui. Ou convertir "size" en int.
for (int i = 0; i < static_cast<int>(tab.size()); ++i)
Cela respecte aussi la recommandation. Mais c'est plus long et il y a un cast en plus, donc c'est pour ça qu'on préfère en général utiliser un unsigned.
Le plus simple reste d'ecrire :
for (std::size_t i = 0; i < tab.size(); ++i)
Léo_c a écrit:
Ce que je n'ai pas compris c'est, est-ce que dans le cas du code qu'a proposer EL-jos au début du sujet cela pose un problème de ne pas mettre un int unsigned ou cela n'aurait pas d'importance dans ce cas la mais pourrait en avoir une dans un autre cas ?
Cela produit un warning par le compilateur. Et c'est une bonne pratique d'activer et corriger les warnings du compilateur.
Mais dans ce cas précis, l'utilisation de int ne va pas produire de comportements étranges, puisque on est sur que i est toujours positif dans ce code.
(Mais si dans la boucle, tu fais la moindre modification de i, par exemple ajouter un --i, tu perds cette garantie)
Le C++ est déjà assez compliqué comme ca. Autant suivre dès le début des règles simples applicables tout le temps plutot que de prendre le risque de faire des erreurs.
Wawou, je vois que cette discussion est vraiment intéressante , avoue le gbdivers.
mais juste une question: un entier signé de 8 bits peut stocké des valeurs allant de -128 à 127 donc on peut dire 256 valeurs;
mais pour quoi en déclarant:
signed int variable{-1};
passe tout les bits à 1 et j'ai essayer d'examiner pour savoir le nombre de bit qui seront à 1(bah! se juste pour contourner ce bug),
boum!!!, c'est 64 bits qui sont à 1, aussi longtemps que un signed int vaut 4 octet donc 32 bits.
Nota: j'ai posé cette question par ce que la norme C++ nous parle juste de conversion(bah! si je me trompe pas) mais pas de ce qui se passe vraiment en interne .
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
> passe tout les bits à 1 et j'ai essayer d'examiner pour savoir le nombre de bit qui seront à 1(bah! se juste pour contourner ce bug),
C'est pas un bug. C'est lie a la façon dont les entiers signes sont représentés en binaire. La méthode ici est celle du complément a 2. Si tu regarde, tu verra que la représentation de -1 en complément a 2 est bien une série de 1. Rien a voir ici avec un quelconque problème de conversion.
J'avoue sans problème que discuter des raisons techniques est plus intéressant que de clore la discussion avec "c'est un choix personnel".
Tes messages sont un peu confus, je ne suis pas sur ce comprendre ce que tu demandes.
Le norme C++ ne parle pas de ce qui se passe en interne, parce que ça n'a pas d'importance. La question n'est pas de savoir ce qui se passe en interne, quand le programme a un comportement qu'on avait pas prévu. Savoir ici que le signed est converti en unsigned et que la représentation en complément a 2 fait que "a > b" n'est pas le plus important.
Le plus important, c'est de savoir ce qui va se passer si je te donne un code que tu ne connais. Si tu es obligé d'exécuter le code pour voir ce qu'il fait et après coup expliquer ce qui se passe, alors tu feras des erreurs en écrivant du code. Ce qui est important, c'est de savoir pourquoi le C++ choisit de convertir le signed en unsigned et pas autre chose.
Ce que tu dis n'est valide que dans le cas du complément a 2, mais tu n'as pas la garantie que c'est toujours ce qui se passe.
Au final, la seule chose que tu as a retenir de notre conversation, c'est la recommandation :
> ne pas mélanger des signed et unsigned
Les restes, c'est du détails techniques.
D'accord, merci pour vos réponses je passe le sujet en résolu
Lire certaines lignes d'un fichier avec qt
× 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.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Discord NaN. Mon site.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Discord NaN. Mon site.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Discord NaN. Mon site.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Discord NaN. Mon site.
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .