yAroTweet (ou le topic des pensées à la con) - Page 522

Zerosquare (./15629) :

Folco (./15624) :
Est-ce que sur PC, on peut lire 4 octets contigus, sans tenir compte de leur alignement ?
Je me fiche d'une éventuelle question de performance, je voudrais juste être sûr de ne pas me taper une bonne Address Error soiçantuikaïque

Tu n'auras pas d'Address Error et en assembleur tu n'auras pas de souci, mais en C c'est pas portable, et je ne suis pas sûr que le compilateur ne puisse pas considérer ça comme une opération non définie. Tu vaux mieux que ça

Il faudra probablement -fno-strict-aliasing parce qu'un tel accès non aligné est probablement de l'aliasing (à moins que ce ne soit une structure packed?), mais à part ça, le compilateur va accepter sans broncher. Mais la plupart des architectures vont te lancer un Address Error ou équivalent, oui.

Il s'agit de lire 4 octets dans un QByteArray, dans lequel j'ai copié tout un fichier. Les 4 octets représentent une taille, et je n'ai aucune certitude quant à un quelconque alignement.
Evidemment, je peux lire les 4 octets à la main ^^

laisse le compilateur se debrouiller t'inquiete

Kevin > justement, c'est de l'aliasing. Ça ne me semble pas une bonne idée de compter là-dessus (que se passe-t-il le jour où le programme est compilé sans le switch par erreur, ou avec un autre compilateur ?)

Folco > même sans le problème d'alignement et le problème d'aliasing, c'est pas portable, à cause de l'endianness. Fais-toi une petite fonction qui lit 4 octets un par un et recompose un uint32_t (et vice-versa), c'est plus propre

Zerosquare (./15634) :
Kevin > justement, c'est de l'aliasing. Ça ne me semble pas une bonne idée de compter là-dessus (que se passe-t-il le jour où le programme est compilé sans le switch par erreur, ou avec un autre compilateur ?)

Au moins Clang/LLVM connaît aussi cette option.

Je trouve quand même risqué d'écrire du code qui ne fonctionne pas (pire, qui semble fonctionner, mais qui peut foirer sans prévenir) avec les options par défaut des compilateurs. C'est le genre de trucs qui revient te hanter tôt ou tard.

Zero: l'utilisation des hton* ntoh* resouds ce probleme de maniere plutot formidable!

Pas vraiment. Ça ne fait que changer l'ordre des octets (donc ça suppose que tu fasses un accès aliasé et potentiellement non aligné). Et ça ne supporte que le big-endian.

A vrai dire il vaux mieux, si on map un fichier en mémoire, utiliser une structuré avec un pack a 1 et pointer la structure sur la zone mémoire.

Et si c'est portable, c'est justement tout l'intérêt du compilateur, quand on passe par ce genre de méthode, plutôt que de jouer avec des pointeurs direct. Le compilateur va faire attention a ce que le code ne fasse pas d'acces non alligné si on est sur une archi qui ne peux pas lire des données non allignée.

Apres pour un probleme de performances c'est un autre sujet, mais si le fichier met des valeurs a des addresses non alignée, tu n'a pas forcement le choix.

A vrai dire, faire une fonction qui va swaper les octets n'est pas forcement des plus pratique, l'avantage d'un fichier mappé en mémoire c'est qu'on peux y acceder en direct, sinon autant lire a coup de (f)read avec la taille dont on a besoin..


Folco: d'ailleurs, a moins d'utiliser Windows (et encore il y a moyen de faire) je te conseilllerais plutot de passer par du mmap, plutot qu'un truc genre

char *buf = malloc(size_of_file)
fread(buf, 1, size_of_file, file);

mmap, contrairement a cette facon de faire te permet de ne pas avoir a gerer la mémoire car c'est l'OS qui gere le mapping mémoire du dit fichier, donc il est capable si besoin est de décharger une partie du fichier de la mémoire, et ensuite recharger.

Tres utile si tu as de tres gros fichiers a mettre en memoire (comme des fichiers qui sont plus gros que l'espace memoire disponible)

Godzil (./15639) :
A vrai dire il vaux mieux, si on map un fichier en mémoire, utiliser une structuré avec un pack a 1 et pointer la structure sur la zone mémoire.

Je ne suis pas sûr que ça soit garanti de fonctionner correctement sur une archi qui ne supporte pas les accès non-alignés. (Et il n'y a pas de façon portable de forcer le packing à 1 octet, même si la plupart des compilos ont une extension pour ça).

Godzil (./15639) :
A vrai dire, faire une fonction qui va swaper les octets n'est pas forcement des plus pratique

Je ne recommande pas de swapper les octets, mais de lire/écrire les octets un par un. Ça peut être fait de manière portable, et ça marche quels que soient les règles d'alignement et de l'endianness de la machine. Évidemment c'est plus lent qu'un accès 32 bits, mais si c'est pour faire du parsing de fichier en général ce n'est pas gênant.

Effectivement, la manière portable de lire un entier 32-bits d'un char * est:
char *p; // variables intermédiaires parce qu'on ne peut pas utiliser plusieurs postincrements dans une même instruction unsigned char c1 = (unsigned char) *(p++); unsigned char c2 = (unsigned char) *(p++); unsigned char c3 = (unsigned char) *(p++); unsigned char c4 = (unsigned char) *(p++); // au choix: uint32_t iBE = ((uint32_t) c1 << 24u) + ((uint32_t) c2 << 16u) + ((uint32_t) c3 << 8u) + (uint32_t) c4; uint32_t iLE = (uint32_t) c1 + ((uint32_t) c2 << 8u) + ((uint32_t) c3 << 16u) + ((uint32_t) c4 << 24u);

Vous vous compliquez, utilisez un truc comme protobuff ou flatbuffer pour sérialiser votre structure sur disque/réseau/whatever avec packing, et pareil pour la relire, elle sera mise en mémoire au bon format. Mais ça impose de la décrire d'une façon ou d'une autre (en général json converti en code généré). La formule magique dans ce domaine n'a toujours pas été trouvée.

On a pas forcément envie de rajouter une dépendance externe pour un petit projet, et les fonctions de lecture/écriture sont relativement simples à écrire.

J'ai fait ça :

int ProjectFile::readSize(QByteArray* array, int index)
{
    int size = array->at(index);
    size += array->at(index + 1) * 8;
    size += array->at(index + 2) * 16;
    size += array->at(index + 3) * 24;
    return size;
}

C'est naïf, et je pensais pas qu'il vallait mieux en passer par là pour être certain que tout se passe bien quelques soient les circonstances.

-* +<<

XD oui shift et pas multiplication

Ben purée elle est belle celle-là

Quelques faits ironiques: 1. L’insigne de la 45e division d’infanterie de l’ U.S. Army était le swastika (le 45 faisait partie de l’ Oklahoma Army National Guard et le swastika était une référence à la large population de natifs américains dans le sud-ouest). 2. Le train privé de Hitler était nommé au début de la guerre “Amerika” 3. Au moment où Pearl Harbor a été attaqué, le commandant de l’U.S. Navy était nommé CINCUS (prononcé “sink us”, “coulez-nous” en français).

http://buzzosphere.net/photos-rares-de-la-seconde-guerre-mondiale/6/

Kenya : https://www.cbsnews.com/news/stray-dog-rescues-abandoned-baby/

USA : https://imgur.com/gallery/zlSJE25

./15645 & ./15646 : pourquoi ? N'importe quel compilateur sorti après les années 1700 produira le même code de toutes façons. Je veux bien que ce soit l'un des rares cas où l'utilisation explicite d'un décalage est envisageable, mais la multiplication ne me semble pas moins lisible ici et vous voir le sortir presque comme un automatisme est curieux.

Parce que mon code est faux, tout simplement ^^
Et c'est quand même plus élégant de décaler de 8, 16 et 24, que de multiplier par 256, 65536 et 16777216

Ah OK, j'avais mal compris l'argument, je pensais qu'ils proposaient de remplacer une multiplication par le décalage équivalent. Ceci dit du coup c'est à toi qui je pose la question également : pourquoi est-ce "plus élégant" (et ça veut dire quoi d'ailleurs) ?

(plus parlant, puisqu'il s'agit de positionner des octets)

Il y a aussi une question d'intention.

Autant remplacer un *2 par un <<1 peux rendre le code moins lisible, autant la ce que Folco veux faire est clairement décaler des bits vers la gauche et ensuite faire un OR avec les dites valeurs. En gros il ne fait pas des maths mais de la manipulation de bits.

Autant 256, 65536 & co sont des valeurs simples et connue d'une majorité, mais

x * 512 tu pense immédiatement a un décalage de 9 bits vers la gauche?

La il ne fait pas des maths, et ne cherche pas a "optimiser" du code, c'est juste qu'il est plus logique d'utiliser un shift qu'une multiplication.

: déjà c'est plus lisible car les constantes sont plus petites, et en plus c'est un cas où l'opération qu'on cherche à effectuer est effectivement un décalage de bits, donc pourquoi utiliser une multiplication ?

Perso je fais même "pire" : j'ai une seule fonction générique avec une boucle, qui prend en paramètre le nombre d'octets sur lequel est stocké l'entier. Du coup, ça gère tous les cas de 8 à 64 bits sans devoir dérouler le code à la main ^^

(après, c'est le genre de débats interminables, comme le fizzbuzz )

I loled :

./15652 - ./15654 : oui, ici c'est légitime, c'est ce que j'entendais derrière "l'un des rares cas où c'est acceptable". Je trouve personnellement les décalages moins rapide à lire, d'autant plus qu'à cause des priorités et il faut souvent ajouter des paires de parenthèses qu'un "* 256" ne requiert pas, mais en effet les goûts et les couleurs

Au niveau sémantique c'est quand même pas pareil, dans un cas on veut décaler des bits et dans l'autre cas évaluer une expression mathématique. Enfin c'est comme ça que je le vois, même si évidemment, la multiplication se justifie dans le sens où c'est une base
Je vote aussi pour les constantes plus petites et à priori plus explicites... pour moi

Nhut (./15623) :
Tu le saurais si tu étais un peu cultivé. Mais tu ne l'es pas.

Ça ne me regarde sans doute pas, mais ce n'est pas très agréable à lire pour autant...

Lemokitu (./15648) :
Kenya : https://www.cbsnews.com/news/stray-dog-rescues-abandoned-baby/

Ça rappelle la légende de Romulus et Remus.