striiiiiiiiiiiiiiing - Page 53

Brunni (./1559) :
Si tu peux t'assurer que ton int est bien 32 bits ton code marche*, mais rien de tout ça n'est garanti en C(++).

En fait, si: http://www.lispworks.com/documentation/lw60/RNIG/html/readme-418.htm
http://en.wikipedia.org/wiki/Stdint.h
(Par contre, à moins que ma mémoire ne me fasse défaut, MS ne livre aucune version de stdint.h avec son compilateur)

Je peux savoir pourquoi tu n'as pas choisi l'endianness de ta machine préférée au fait?

Hmm, j'ai bien utilisé le Intel Byte Order non ?

* en fait il marche pas non plus, mais t'en es pas loin

Bah j'écris le code à la volée et plutôt générique (d'où les INT32, BOOL, etc. en majuscules) et je ne le teste pas sur un compilo donc c'est fort possible.
Si t'avais précisé pourquoi ça serait encore mieux, car c'est surtout Folco que ça pourrait gêner, pas moi ^^

Ho scuse j'ai pris ton post pour étant de Folco
A ce moment ça n'est pas sympa d'avoir posté un bout de code, je disais à Folco que c'était un bon entrainement de le faire Mais il n'a pas encore la version générique
La raison: >>32
Et heu voilà, stdint est une bonne initiative mais ne marche pas partout. Mais de toute façon c'est vrai qu'il faudra fixer les types sinon les fichiers ne seront pas portables, donc pas forcément besoin des fonctions génériques.

EDIT : oui, Visual C++ ne supporte TOUJOURS pas stdint, qui date pourtant de C99...
Quand je fais un code qui doit marcher sur un compilo MS, je rajoute un #define conditionnel pour ce cas-là.

Brunni (./1562) :
A ce moment ça n'est pas sympa d'avoir posté un bout de code, je disais à Folco que c'était un bon entrainement de le faire Mais il n'a pas encore la version générique

Euh j'ai des grosse lacunes, ok, mais venant de l'asm, je sais quand même ce qu'est une rotation de bits et quand s'en servir hein

La raison: >>32

Ah, exact

Zerosquare (./1563) :
EDIT : oui, Visual C++ ne supporte TOUJOURS pas stdint, qui date pourtant de C99...

VC++ n'a rien à foutre du C99, du coup, moi, je n'ai rien à foutre de VC++, de toute façon, il y a MinGW qui marche très bien et qui fournit stdint.h.

MinGW est peut-être très bien, mais tu l'utiliseras (plus ?) jamais

J'utilise cross-MinGW afin de permettre aux utilisateurs de systèmes d'exploitation inférieurs d'utiliser mes logiciels libres.

Tiens un truc dans la même lignée, si je fais un malloc (sizeof (struct chose)), l'implémentation fera en sorte que le 'sizeof (struct chose)' soit de la taille réelle de la structure représentée en mémoire, pas juste de la somme de la taille de ses éléments ?

typedf struct {uint16 x, uint16 y} chose;

S'il décide d'aligner les words sur 4 octets, 'sizeof (struct chose)' fera bien 64 octets, pas 32 ? Pas de risque de se faire avoir ?

Folco (./1569) :
Tiens un truc dans la même lignée, si je fais un malloc (sizeof (struct chose)), l'implémentation fera en sorte que le 'sizeof (struct chose)' soit de la taille réelle de la structure représentée en mémoire, pas juste de la somme de la taille de ses éléments ?

Oui, heureusement!

Ouf, mais puisqu'on était dans le sujet, je voulais être sûr de tout à la fois.

Merci

C'est un peu le but de sizeof en meme temps, de pouvoir savoir a la compilation l'espace utilisé par le type donné en parametre

Oui, c'est bien vrai

Bon, voilà ce que j'ai écrit :

    for (i = 0; i < numberEntries; i++)
    {
        fread (&(cData[i].playerName), 1, 20, scoresFile);
        readUint16_t (scoresFile, &(cData[i].score));
        readUint16_t (scoresFile, &(cData[i].BV));
        readUint16_t (scoresFile, &(cData[i].V));
        readUint16_t (scoresFile, &(cData[i].TV));
        readUint16_t (scoresFile, &(cData[i].lostATGuns));
        readUint16_t (scoresFile, &(cData[i].lostAAGuns));
        readUint16_t (scoresFile, &(cData[i].lostARTGuns));
        readUint16_t (scoresFile, &(cData[i].lostTanks));
        readUint16_t (scoresFile, &(cData[i].lostRecons));
        readUint16_t (scoresFile, &(cData[i].lostInfanteries));
        readUint16_t (scoresFile, &(cData[i].lostFighters));
        readUint16_t (scoresFile, &(cData[i].lostBombers));
        readUint16_t (scoresFile, &(cData[i].killedATGuns));
        readUint16_t (scoresFile, &(cData[i].killedAAGuns));
        readUint16_t (scoresFile, &(cData[i].killedARTGuns));
        readUint16_t (scoresFile, &(cData[i].killedTanks));
        readUint16_t (scoresFile, &(cData[i].killedRecons));
        readUint16_t (scoresFile, &(cData[i].killedInfanteries));
        readUint16_t (scoresFile, &(cData[i].killedFighters));
        readUint16_t (scoresFile, &(cData[i].killedBombers));
    }

    if (ferror (scoresFile) == 0)
        goto Success;

Avec :

int readUint16_t (FILE* stream, uint16_t* target)
{
    int a, b;
    if ((fread (&a, 1, 1, stream) != 1) || (fread (&b, 1, 1, stream) != 1))
        return 0;
    *target = (a << 8) + b;
    return 1;
}

Je n'ai vu nulle part que lire sur un flux qui a son flag d'erreur activé pouvait poser un problème, j'imagine juste que les fonctions fread/fwrite deviennent inopérantes jusqu'à ce qu'on appelle clearerr(). Donc je pense pouvoir me contenter de tester ferror qu'une fois la fin des lectures atteinte plutôt qu'à chaque accès.

des "unsigned char" serait a mon avis plus aproprié pour a et b que des int mais bon c'est tres perso.

Tester ferror une seule fois ? tu ferrais mieux de tester le retour de ta fonction write, ferror peux ne pas te donner une info fiable, et puis ça evite de faire 1500 tours de boucles alors que tu peux sortir de suite, et sans compter que le pbm sur UNE ecrite peux etre temporaire et que les suivantes fonctionnent correctement...


Je te conseille plutot, si tu veux pas te faire chier a tester tout les retours de faire un truc genre :
char readUint16_t (FILE* stream, uint16_t* target) { unsigned a, b; if ((fread (&a, 1, 1, stream) != 1) || (fread (&b, 1, 1, stream) != 1)) return 1; *target = ((a&0xFF) << 8) | (b & 0xFF); return 0; } void saveHighscore(...) { int err = 0; [...] for (i = 0; (i < numberEntries) && (err == 0); i++) { err = 0; err += (fread (&(cData[i].playerName), 1, 20, scoresFile) != 20)?1:0; err += readUint16_t (scoresFile, &(cData[i].score)); err += readUint16_t (scoresFile, &(cData[i].BV)); err += readUint16_t (scoresFile, &(cData[i].V)); err += readUint16_t (scoresFile, &(cData[i].TV)); err += readUint16_t (scoresFile, &(cData[i].lostATGuns)); err += readUint16_t (scoresFile, &(cData[i].lostAAGuns)); err += readUint16_t (scoresFile, &(cData[i].lostARTGuns)); err += readUint16_t (scoresFile, &(cData[i].lostTanks)); err += readUint16_t (scoresFile, &(cData[i].lostRecons)); err += readUint16_t (scoresFile, &(cData[i].lostInfanteries)); err += readUint16_t (scoresFile, &(cData[i].lostFighters)); err += readUint16_t (scoresFile, &(cData[i].lostBombers)); err += readUint16_t (scoresFile, &(cData[i].killedATGuns)); err += readUint16_t (scoresFile, &(cData[i].killedAAGuns)); err += readUint16_t (scoresFile, &(cData[i].killedARTGuns)); err += readUint16_t (scoresFile, &(cData[i].killedTanks)); err += readUint16_t (scoresFile, &(cData[i].killedRecons)); err += readUint16_t (scoresFile, &(cData[i].killedInfanteries)); err += readUint16_t (scoresFile, &(cData[i].killedFighters)); err += readUint16_t (scoresFile, &(cData[i].killedBombers)); } if (err > 0) /* Do whatever you want in case of one or more error, and here you know how much error you have */ }

J'ai inversé la valeur de retour de va fonction de lecture

Les "& 0xFF" peuvent paraitre superflu, mais evite bien des soucis dans certain cas "étrange". Prefere utiliser un ou logique ( | ) au + quand tu agence des octets entre eux, l'utilisation de | est plus logique que le "+", et si tu te plante du nombre de décallage (voir tu fais expres pour X ou Y raison) le + n'a pas le meme sens que le | (ie (3 << 1) | 3 n'a pas la meme valeur que (3<<1) + 3)

Godzil (./1574) :
Les "& 0xFF" peuvent paraitre superflu, mais evite bien des soucis dans certain cas "étrange"

Ok. Peut-être dans des cas de casts ? S'il y a des infos sur "pourquoi le proc/l'implémentation peut faire de la merde sans ça", je veux bien, ça m'intéresse de comprendre pourquoi.

En attendant, c'est implanté.

Godzil (./1574) :
Prefere utiliser un ou logique ( | ) au + quand tu agence des octets entre eux, l'utilisation de | est plus logique que le "+"

En effet. Le problème, c'est que c'est certainement abordé sous l'angle "logique" dans les cours, ce qui parait assez abstrait quand on fait de l'assembleur : c'est strictement identique donc on s'en fout.

Mais dans mon bouquin de C, les &|^ et les << >> sont dans le même chapitre évidemment.

Godzil (./1574) :
des "unsigned char" serait a mon avis plus aproprié pour a et b que des int mais bon c'est tres perso.

Flemme de tester ce qu'il restait d'un char après un '<< 8' En tout cas, en asm, pouf ton char. Là, ça dépend si le cast en int est fait avant ou après la rotation, pas vérifié.

Et si j'ai bien compris ce qui se passe au niveau des casts automatiques, je peux toujours partir du principe que la conversion de 'truc' du type A vers le type B peux s'écrire : (B)((int) truc) : passage par la case int de toute façon, quitte à ce que ce soit zappé grâce aux optimisations au niveau assembleur. Donc je ne crois pas, ici, perdre en efficacité.


(ps: durant toute la première partie du post, je croyais répondre à squalyl, putain de fake-avatar )

Pourquoi pas un seul char buffer[2] au lieu de int a, b ?
Ça serait bien plus efficace de lire les deux d'un coup plutôt qu'en deux fois non ?

Parce que j'ai cru devoir faire ça pour maitriser l'endianness... Mais tu as raison apparemment.


ps -> Godzil, pas mal du tout le coup du comptage de nombre d'erreurs.

par contre fait super gaffe a l'ordre des parametres de fread/fwrite, un des parametres lui indique le nombre d'octet par lecture et l'autre le nombre de lecture, et le comportement est différent si tu inverse les valeurs ! (meme si au final tu as le meme nombre d'octet lus)

ie si tu fait une lecteur par "octet" il faut lui dire que la taille et de 1 et faire 2 lectures.

Si tu travaille sur des structures (c'est pas le top a cause des pbm de endianess) il faut lui dire "je travaille avec des sizeof(struct) et je veux en lire "X")

Et la valeur retourné par fread/fwrite n'est PAS le nombre d'octet lu, mais le nombre de block de taille indiqué correctement lu.

GC: je suis pas sur que ça soit bcp plus efficace, mais ça economise au moins un peu de code

Godzil (./1574) :
Tester ferror une seule fois ? tu ferrais mieux de tester le retour de ta fonction write, ferror peux ne pas te donner une info fiable, et puis ça evite de faire 1500 tours de boucles alors que tu peux sortir de suite, et sans compter que le pbm sur UNE ecrite peux etre temporaire et que les suivantes fonctionnent correctement...

J'ai pas percuté quand j'ai lu ça, j'avais oublié ce que pourtant, j'était allé lire 10 minutes avant dans le man de ferror :

       La  fonction  ferror()  teste  l’indicateur d’erreur du flux pointé par
       stream, et renvoie une valeur non nulle si cet  indicateur  est  actif.
       L’indicateur  d’erreur  ne  peut  être réinitialisé que par la fonction
       clearerr().

Donc d'après man l'erreur est persistante, et je n'ai aucun risque d'avoir une erreur silencieuse. J'espère que c'est juste normalisé, et ça, je ne sais pas comment le vérifier par contre
Quand au nombre de tours de boucles, il est de toute façon très minime (max : 5).

if ((fread (&a, 1, 1, stream) != 1) || (fread (&b, 1, 1, stream) != 1))
Au fait l'ordre d'évaluation des conditions est défini dans la norme? (j'hésite à chaque fois)

Oui.

(en C comme en C++ d'ailleurs)

(et comme dans tous les autres langages dérivés aussi )
D'ailleurs, les parenthèses autour des opérateurs de comparaison ne sont pas nécessaires. (voir le code cité en ./1580 )
Tous les opérateurs de comparaison (>, >=, < et <= étant eux-mêmes prioritaires sur == et ! sont prioritaires sur && qui est lui-même prioritaire sur ||. Les détails exacts peuvent varier d'un langage à l'autre, mais à ma connaissance, cette relation d'ordre est vérifiée en C, C++, Java, C#, JavaScript (/ECMAScript), PHP, donc pas de risque à s'en servir
(Et n'hésites pas à consulter les tables de priorité des opérateurs si tu as un doute !)

./1573 Et si sur la plateforme où tu exécutes ton code, les char ne faisaient pas 8 bits, il se passerait quoi ?

Ah Thepro, on m'a interdit de penser à ça il y a quelques pages Mais je suis bien d'accord, ça casserait.
Pour être rigoureux, je devrais vérifier que sizeof(char) * 2 == sizeof(uint16_t), et agir différemment si sizeof(char) == sizeof(uint16_t).

T'utilises int8_t (ou uint8_t) à la place de char et puis basta.
Sur les machines dont les char ne font pas 8 bits, int8_t n'est pas implémentable et donc inttypes.h non plus -> ça te donne une bonne excuse pour ne pas supporter ces machines

./1585> Sur le principe c'est sûr qu'ils pourraient changer (ce serait pratique d'avoir un type char "wide" natif comme en Java) mais en pratique ça ne sera jamais le cas.
Le C n'est plus sur les feux de la rampe, ils ne vont pas s'amuser à revoir ce genre de concepts fondamentaux parce que trop de monde se base dessus. En fait c'est juste que char aurait dû s'appeler byte et ils auraient dû prévoir un type différent dès le départ, les char étant 7 bits de toute façon.

Brunni (./1587) :
Ce serait pratique d'avoir un type char "wide" natif comme en C#.

Comme par exemple wchar_t ? Celà étant dit je rappelle quand même que sizeof(wchar_t) n'a pas été fixé par la norme

Le C n'est plus sur les feux de la rampe, ils ne vont pas s'amuser à revoir ce genre de concepts fondamentaux.

Bah tout ce qui aurait du être normalisé a été normalisé. Les intNN_t font partie de la norme C99, tout comme les wchar_t ainsi que complex, etc.
Après le langage ne peut plus trop évoluer donc c'est normal qu'on y touche plus trop. (C'est ni un langage objet ni un langage de scripts donc y'a pas grand chose à y apporter)
Pour les évolutions y'a le C++(1x)

(Je connais wchar_t mais c'est pas transparent... en principe si 'char' était dépendant du système, la stdlib pourrait fonctionner partout et pas seulement en ANSI, CA ce serait bien.)
Justement, ils ne toucheront pas à ça, ils ne peuvent que rajouter des types et *au pire* déconseiller l'utilisation des vieux types.
En fait je voulais dire par là qu'ils ne cherchent pas à faire du C un "beau" langage, contrairement à Python par exemple qui est en constante évolution, quitte à tout péter. On connaît ses défauts, mais on les laisse parce que les gens font avec ^^

Quels défauts ? C'est un langage bas niveau, il a des caractéristiques de langage bas niveau, c'est tout. (En plus je vois pas quoi corriger sans casser tout le code existant)
Seul un langage haut niveau peut imposer strictement sizeof(int) == 4 (comme le fait C#) ou ce genre de choses. Le C a été prévu pour pouvoir être utilisé partout, pas nécessairement pour que tous les codes en C tournent partout.
Ce que tu vois comme un défaut n'en est pas un dans tous les cas. C'est au pire, un truc super chiant. Mais il y a d'autres langages si le C ne te plaît pas, et tu aurais tort de t'en priver si tu as le choix. (Ce qui n'est pas toujours le cas, on est d'accord)