Discussion :

[bretho_q]

bonjour,

J'ai créer une fonction avec les appels système read/write qui lis un fichier .txt par exemple.
Maintenant je voudrais par exemple additionner tout les nombres qu il y aurais dans le fichier .txt, mais je n'y arrive pas.

quelqu'un aurait il une idée ?

Merci

Voici le fichier.txt:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
45
51
214
85
624
41

Voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
#include<stdio.h>
#include<stdlib.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<string.h>
#include<unistd.h>
 
int main(int argc, char *argv[])
{
  int fd;
  int ecris;
  int lu;
  char buffer[1024];
  char *pathname;
 
  pathname = argv[1];
  fd = open(pathname, O_RDONLY);
 
  if (argc != 2)
    {
      write(2, "error argument\n", sizeof("error argument\n"));
      exit(EXIT_FAILURE);
    }
 
  if (fd == -1)
    {
      write(2, "open error\n", strlen("open_error\n"));
      exit(EXIT_FAILURE);
    }
  else
    {
 
      do
	{
	  lu = read(fd, buffer, 1);
	  ecris = write(1, buffer, lu);
	  if (lu == -1 || ecris == -1)
	    {
	      write(2, "read/write error\n", sizeof("read/write error\n"));
	      close(fd);
	      exit(EXIT_FAILURE);
	    }
	}while (lu != 0);
    }
  close(fd);
  return (0);
}

[Metalman]

1) Dans read/write, évite d'utiliser les nombres 0/1/2... car moi-même je ne sais plus lequel fait quoi... apprends plutôt par coeur les classiques : STDOUT_FILENO, STDERR_FILENO, STDIN_FILENO (facile de retenir : STandarD IN/OUT/ERRor _ FILE Number... vu que sur UNIX tout est fichier...)

2) Tu lis par bloc de 1... c'est bien !
Mais il te faudrait lire char par char, et dès que tu tombes sur un chiffre, le mettre dans un entier, et tant que le suivant est "aussi" un chiffre, tu multiplies l'entier par 10, et tu ajoutes la valeur du chiffre !
Dès que ce que tu lis n'est plus un chiffre, alors tu as lu un nombre complet....
...et tu peux l'ajouter aux autres nombres dans une autre variable.

Attention ! '0' ne vaut pas 0 (et '1' ne vaut pas 1....), il faut faire un espèce de switch OU une soustraction depuis la table ascii (man ascii).

[Bktero]

Bonjour,

Je te conseille de passer par fopen() et fread() qui sont des fonctions standards du C et non des fonctions POSIX.

Ensuite, j'utiliserai plutôt fscanf() pour récupérer des nombres. Ensuite, une simple boucle de lecture et d'accumulation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
 
int main(void)
{
    errno = 0;
    FILE* file = fopen("data.txt", "rb");
 
    if(file == NULL)
    {
        perror("fopen()");
        exit(EXIT_FAILURE);
    }
 
    int buffer = 0;
    int sum = 0;
    while(fscanf(file, "%d", &buffer) == 1)
    {
        sum += buffer;
    }
 
    return sum;
}

[Metalman]

"bretho_q" : ça sent l'epi-login...
Donc seuls open/read/write/close sont autorisés en lecture de fichiers.
Les printf, scanf, fopen, ... sont interdits à mon avis.

Et si je vais voir l'intra... ce monsieur est close compte....

EDIT : Mais pour ceux qui ne sont PAS à Epita, Epitech ou 42... la solution de Bktero est "meilleure" dans le respect des standards !

[edgarjacobs]

Hello,

Tiens, il me semble avoir déjà vu cette question (et ce code) quelque part....

Il faut remplacer les sizeof() par des strlen(). Tel que c'est là, ça ne fera pas planter le programme, mais les messages seront tronqués.

Edgar.

[Médinoc]

Franchement, ça ne me dérange pas trop qu'Epit(a|ech) apprenne read/write à ses étudiants... Par contre, qu'ils leur apprennent 0/1/2 au lieu de STD(IN|OUT|ERR)_FILENO, c'est selon moi une mauvaise pratique.

[Metalman]

Nan ça n'est pas appris "pour bien coder" le 0/1/2.
On nous le dit qu'il s'agit des 3 premiers depuis 0, mais c'est par flemme (et SURTOUT pour dépassement des 80 cols 25 lignes) que l'on met les chiffres.

[Médinoc]

Ça aussi, je trouve que c'est vachement arbitraire... Je préfère avoir une fonction lisible et commentée même si elle ne tient pas sur un terminal qu'avoir un code "compact" mais digne du "12 days of Christmas" de l'IOCCC...

PS: Et mon switch sur 30 valeurs, je dois le splitter sur deux fonctions? Et l'enum elle aussi est-elle limitée à 23 valeurs?

[Metalman]

L'énumération fait la taille qu'elle veut : c'est dans le .h donc hors fonction.

Un switch de plus de 10... c'est... que tu veux gérer un comportement par touche de clavier ?
Bref, c'est assez rare d'avoir une énum pareille.
Et "au pire" si tu en as besoin, bah oui tu couperas en plusieurs bouts, vu que l'énum sera "obligatoirement" un char ou un int.

Le but de ce "micro découpage" c'est de découper en micro-fonctionnalités.
Car ce qui est court est plus facilement compréhensible qu'un gigantesque main faisant tout et rien sur 1337 lignes.

[Bktero]

Se mettre des contraintes arbitraires, inutiles, dénuées de sens, contre-productives est profondément bête.

[Metalman]

C'est "la norme" pour apprendre que "souvent" en entreprise il y a des normes plus ou moins similaires pour éviter le code spaghetti.

Bref, apprendre à la dure ça n'est pas mauvais en soi...
C'est une méthode parmi d'autres...
Venez me dire que faire des fonctions courtes c'est mal, et que globalement, la solution la plus simple est sûrement la plus mauvaise.

EDIT : les vrais abrutis sont ceux qui codent "en dehors de l'école" encore avec cette norme et qui critiquent TOUS ceux qui font + de 80/25 (le 120 colonnes sur 40 lignes est beaucoup plus humain pour du C, et suffisamment large pour ne pas trop perdre le mainteneur).
Le but de cette norme c'est d'apprendre à faire "court", et correctement découpé.

[Médinoc]

IMPOSER des fonctions courtes c'est mal, surtout quand ça se met en travers du chemin des autres critères de lisibilités (noms de variables clairs et explicites, commentaires, etc.)

[Metalman]

Ouais mais ces critères sont "aussi" vérifiés.

EDIT : je remets l'EDIT d'en haut au cas où :
Les vrais abrutis sont ceux qui codent "en dehors de l'école" encore avec cette norme et qui critiquent TOUS ceux qui font + de 80/25 (le 120 colonnes sur 40 lignes est beaucoup plus humain pour du C, et suffisamment large pour ne pas trop perdre le mainteneur).
Le but de cette norme c'est d'apprendre à faire "court", et correctement découpé.

[pfeuh]

Salut,

Le but de cette norme c'est d'apprendre à faire "court", et correctement découpé.

Faire court, c'est bien. Faire court et compréhensible, c'est mieux. Si on ne peut pas faire court et compréhensible, on fait long et compréhensible mais pas court simplement parce que c'est plus joli dans un éditeur. L'école est une chose, la vie réelle en est une autre. C'est ce que m'ont appris les gros projets collaboratifs où l'on perd son temps à essayer de comprendre ce qu'on voulu faire les collègues... Généralement pour chasser un de leurs bugs. Maintenant, si l'on veut bosser tout seul dans son coin après avoir appris tout seul sur les bancs de l'école, c'est une autre affaire. Mais clairement le marché ne s'oriente pas vers ce genre de codage.

A+

Pfeuh

[Metalman]

Je crois que l'EDIT je dois le re-écrire une 3e fois pour que ça soit clair :

Les vrais abrutis sont ceux qui codent "en dehors de l'école" encore avec cette norme et qui critiquent TOUS ceux qui font + de 80/25 (le 120 colonnes sur 40 lignes est beaucoup plus humain pour du C, et suffisamment large pour ne pas trop perdre le mainteneur).
Le but de cette norme c'est d'apprendre à faire "court", et correctement découpé.

On a eu la chance dans ces écoles d'apprendre que l'industrie utilise des normes, et on nous en a imposé une pour tous les projets.
S'il faut TOUT apprendre dans l'industrie, les écoles ne servent plus à rien.

EDIT : j'espère qu'ailleurs "aussi" il y a des projets collaboratifs...

[Damdoshi]

PS: Et mon switch sur 30 valeurs, je dois le splitter sur deux fonctions? Et l'enum elle aussi est-elle limitée à 23 valeurs?

Pour ton switch de 30 valeurs, on va surtout te dire de créer un tableau de pointeur sur fonction dont l'index sera la valeur que tu souhaitais passer à ton switch, SURTOUT si la valeur attendue est une énumération.
Il y a d'autres méthodes si les valeurs ne sont pas contigus, il y a une solution pour tout.
Peut être n'avais tu pas dans l'idée d'uniformiser l'ensemble de tes cas (Afin de faire correspondre la réponse a chacun a un unique type de pointeur sur fonction), mais si c'est le cas, tu devrais y réfléchir.

Faire court, c'est bien. Faire court et compréhensible, c'est mieux.

Tu pars du principe que c'est incompréhensible: Tu te trompes.

La norme des écoles du groupe IONIS peut se trouver sur Internet, et tous les critères que l'on peut y trouver, a quelques détails près fait pour repérer les tricheurs, sont les même que ceux développés par la majorité des codings style.

Le maître-mot est qu'une fonction doit pouvoir s'expliquer par elle-même par son nom, son type de retour et ses arguments. Si celle ci s'avère complexe, un en-tête commenté pourra l'expliquer.
Cela afin qu'une fonction ne fasse qu'une chose, soit réutilisable dans un contexte différent et facile à utiliser par un autre, et bien sur, qu'elle reste simple.
Dans le même esprit, on place une seule fonction non statique par fichier. Pour que tout soit aéré, facile et immédiat.


Les correcteurs sont humains, et nous détestons le code dégueulasse, forcement vu qu'on est censé le lire, le comprendre et le critiquer en 15 minutes de soutenance et que cela n'est pas vraiment un exercice évident.

Vous vous doutez bien que l’intérêt de l'exercice n'est pas d'enlaidir le code!!



----------------------


Edit:
Pour répondre a l'auteur du topic.

Pour ce qui est de la lecture dans le fichier, pose toi la question: quelle taille fait ce que je suis censé lire?
Tu ne peux pas savoir, donc il faut que tu trouves le moyen de stocker ce que tu lis avant de l'interpreter, tu peux aussi interpreter au fur et a mesure, mais tu auras plus de difficulté.
La, tu écris dans buffer, mais toujours au premier octet! Du coup, chaque enregistrement ecrase le precedent.

Ensuite...
Dans ce fichier, que comptes tu y trouver?
Des chiffres séparés par des sauts de lignes (et éventuellement, des espaces a ignorer).
Par exemple:
"-21\n-42\n-84\n0 "

Tu commences au début, la question que tu dois te poser est: "Qu'est ce que je suis censé trouver?"
Un chiffre? Alors verifie que tu as un chiffre en testant la valeur, et si c'est le cas, lis le chiffre
avec la fonction approprié, t'en as forcement fait une, normalement le deuxieme ou troisieme jour de C.
Une fois que tu l'as lu (C'est a dire enregistrer sa valeur puis sauter les caracteres qui lui correspondent), qu'as tu?
Des espaces? Alors avance jusqu'a ce qu'il n'y en ai plus, vu qu'ils ne sont pas important.
Un saut de ligne? Alors mange le, et c'est reparti, tu attends de nouveau un chiffre.

[Kannagi]

Pour ma part je préfère voir une longue variable mais explicite que les variables courte mais qui n'ont aucun sens , les fameuse variables a une lettre par exemple.
Le seul défaut que je vois dans une variable (ou fonction)trop longue c'est que c'est moins pratique a utilisé.

Du 0,1,2 c'est par parlant c'est pour ça que les defines existe , comme on dit c'est pour les chiens , comme la lib standard autant l'utilisé (même si recodé certaine fonction ça peut être formateur pour les nouveaux).

@Bktero t'as oublié un fclose , même si sur ton exemple ce n'est pas très grave vu que c'est dans le main est donc le fichier sera automatiquement fermé , mais je prend habitude de mettre des fclose vu le bug 'horrible' qu'on peut avoir qu'on on le met pas par oublie (le flux déconne et tous les printf bug).

[Damdoshi]

Le nom d'une variable doit etre explicite, quelque soit sa longueur. Surtout si sa durée de vie est longue...
Il est précisé par ailleurs dans la norme dont il est question que les acronymes ou mnémoniques doivent être explicite (Sinon, c'est 1 points qui saute automatiquement)

Comme tu dis, pour les nouveaux, c'est formateur. Et précisément, c'est en première année que la libC a quelques exceptions près est interdite. Une bonne partie des projets et exercices de début d'année consistent à recoder ces fonctions.
Les bibliothèques ainsi formée doivent ensuite être employé par l'étudiant dans ses projets, l'obligeant à effectuer des vérifications, une maintenance, en quelque sorte, de sa bibliothèque, car ses projets reposent dessus. C'est tout un univers technique qui se crée la première année.

En deuxième année, on a le droit a la libC, a quelques exceptions près (Genre, malloc, pour le projet malloc...)

Il n'est fait aucune mention de ces constantes symboliques, pas plus que d'autre éléments non cruciaux, la seule mention faite est... "man"!
Ceux qui ouvrent leur manuel, prennent le temps d'explorer les en-tetes standards utilisent ces constantes symboliques. Les autres non.
C'est aussi un bon indicateur.



Edit:
L'est pas venu à l'école depuis février dernier. Il a du lâcher l'éponge. Il peut utiliser les flux.

[Bktero]

@Bktero t'as oublié un fclose

Oui, tu as raison.

Je n'ai pas vérifié pourquoi fscanf() échoue également, ça peut être intéressant de le savoir (avec feof() et ferror()).

[JulieCarree]

Bonjour,
je trouve ce fil très interessant, n'étant ni étudiant, ni pro de l'info, je comprends mieux les réponses et questions du forum C.