Y'a du niveau Oo

Et maintenant on écoute le groupe "Rétro collection inutile" avec le titre "Mes PC neufs ont des proco de vingt ans".

D'après wiki, le "vrai" Gérard ne faisait que des débats, il ne faisait pas DJ...

Au moins, c'est cohérent avec le résultat de ton examen http://www.pebkac.fr/pebkac/8090/ si tu avais écouté en cours, tu n'aurais pas eu une bulle.

cela dit, question sérieuse, est-ce toujours valable si tu développes par exemple pour des solutions embarquées avec des processeurs <32bits ? (je n'y connais rien, pas taper si c'est une connerie)

Je vais avoir besoin de l'aide du Captain, parce que 16 ou 32 bits je ne vois pas pourquoi une structure de données ne serait pas contiguë.

Par contre, ton état m'inquiète, ce n'est pas la première fois que tu demandes en quelle année nous sommes ;)

En plus, il se répond à lui-même. Je téléphone au Dr Médard (le psy de la série éponyme).

Le stade suivant, c'est de demander si on le reçoit, en ponctuant ses phrases par des "ALLO" :X

J'ai peur.

Il annonçait aussi les chansons, coupant ses débats, par des titres débiles.

J'ai limite envie de dire CTLP, car la position des champs et la taille des structures dépend effectivement de l'alignement.
Donc à part un seul mot qui n'est plus d'actualité (même pas faux, juste plus à jour), la remarque du prof est pertinente.

Ah, ben je ne pouvais pas le deviner, messieurs les moinsseurs.

Quand j'ai entendu parler de ce concept, j'avais fait quelques tests sur ma machine (proco 64 bits) et il y a bien alignement des données.

Si je déclare st1 :

struct st1{
     char a;
     int b;
 };

La structure st1 occupe 8 octets sur ma machine.

À moins que j'ai fait une erreur, je vote CTLP. Mais je vais attendre un peu.

Effectivement c'est lui le PEBKAC car l'alignement provoque ce genre de désagrément et utiliser l'arithmétique des pointeurs dans ce cas peut poser de gros problèmes. L'exemple de @Shirluban le démontre déjà en partie mais on peut être encore plus vicieux.

struct s{
int i;
char a __attribute__((aligned(8)));
};

std::cout<<sizeof(s)<<std::endl;

nous dit 16 ^^ .

le int par définition a une taille de bit variable équivalente au nombre de bits du système pour lequel le programme à été compilé sur un systeme 16 bits il a donc une taille de ... 16 bits et est donc strictement équivalent au short, le type de 32 bits standard et "stable" est le long (et long long pour le 64 bits)

de fait le int est toujours parfaitement aligné.

de plus pour ce qui est de l'alignement, les compilateurs actuels savent plutôt bien corriger les défaut d'alignement provoqué par le codeur quand il y en a, ce qui ne doit pas empêcher de penser un minimum a l'alignement surtout pour une structure.

donc PEBKAC ? si le prof pense que le int est toujours supérieur a 16 bits oui, sinon je ne sait qu'en penser, l'utilisation du short pour économiser de la place en mémoire est un argument valable selon ce qu'on en fait.

Il est plus facile/rapide de lie une donnée qui est aligné en mémoire sur les mots (généralement 16, 32 ou 64 bits suivant l'architecture).
La lecture en mémoire se fait par mots entiers, pris à des adresses multiples de la taille des mots.
Par exemple, sur 8 octets avec des mots de 16 bits:

12345678   <- adresse
 ..==..==   <- limites des mots
   AA BB    <- données

La variable AA est aligné en mémoire, le système n'aura besoin que d'une action pour la lire, puisqu'il récupère directement le mot aux octets 3 et 4.
La variable BB n'est pas aligné en mémoire, le système devra d'abord lire le mot aux octets 5 et 6, puis le mot aux octets 7 et 8, en enfin transformer les deux pour reconstituer la valeur BB.

Pour optimiser les temps d'accès, le compilateur s'arrange pour que les données soient alignés sur les mots.
Par exemple si on a une variable S sur 2 octets et une variable L sur 4 octets, on aura:
Sur un système 16 bits:

12345678   <- adresse
 ..==..==   <- limites des mots 16 bits
 SSLLLL     <- données

Sur un système 32 bits:

12345678   <- adresse
 ....====   <- limites des mots 32 bits
 SS  LLLL   <- données

Sans lire le nom de l'auteur, j'ai tout de suite deviné que cette anecdote ne pouvait venir que de l'école de Lynix !!!
Je ne m'étais jamais intéressé à l'alignement des variables dans la programmation informatique, mais par contre, sur des micro-contrôleurs j'y faisait attention (surtout quand j'utilise des résultats de CAN sur 10 bits... qui prennent évidemment 2 octets de mémoire....)
sinon, je n'ai pas ni assez de connaissances ni d'expérience pour juger cette anecdote...

Clem n'a pas bien édité mon PEBKAC :(

Dans la version originale, de ce que je m'en souviens, je précise bien que c'est faux parce que nous utilisons maintenant des processeurs 32/64 bits, et que donc du coup l'alignement ne se fait pas sur des adresses paires (ou 16 bits), mais sur du 32/64 bits, comme le prouve le code de Noname.

Le PEBKAC ici est sur mon école qui n'a pas dépassé le stade du 16bits.

Attends... tu veux dire que la taille d'un mot varie selon si on est sur un système 16bits, 32bits ou 64bits ?
T_T et dire qu'à l'époque où j'apprenais le C, on nous avait appris appris qu'un mot fait 2 octets, point. (on était sous des systèmes 32bits).

Je savais que notre prof était un nul, mais je n'aurai jamais cru redécouvrir sa nullité après tant d'années...

Bon sang, le jour où je veux me remettre à faire de la vraie prog., il va me falloir reprendre certaines choses depuis le début je crois...

"J'étais un peu dissipé"... Du coup, il prend une phrase du prof sortie du contexte et décide que c'est un PEBKAC... Peut-être que mis dans le bon contexte ce n'en était pas un. Du coup, je vote CTLP, parce que c'est en manquant d'humilité (au vu des précédentes anecdotes, ça m'a l'air d'être le cas du personnage) qu'on devient un vrai PEBKAC.

Arf dommage ! Le mieux en fait ç'aurait été de dire que de toute façon l'alignement peut être bien plus grand que l'on croit. D'ailleurs il peut faire plus que 32/64bits ;) :

struct bidon{
__m128i reg;
int a;
};

Hop alignement sur 128 bits ^^ .

Et puis d'abord être dissipé en cours, c'est mal ! ^^

Attention!
Je parle de mots du point de vue de l'architecture.
Dans le langage "courant", on continu d'utiliser les termes WORD, DWORD et QWORD suivant leur définition sur les systèmes 16 bits, ce qui ne correspond plus à la taille réelle des mots du système.

Oui après j'ai pas non plus dit que c'était forcément aligné sur du 32/64 bits, si je prends un très vieux compilateur il pourrait aligner sur du 16 bits aussi.

Juste que dire que c'est forcément aligné sur du 16 bits comme l'a dit ma prof, c'est une grosse connerie.

Le fait que j'aie été un peu dissipé ne voulait pas dire que je n'écoutais pas ce qui était dit, c'est d'ailleurs ça qui m'a dissipé (D'entendre parler encore et encore des mêmes trucs), jusqu'à ce qu'elle parle de l'alignement où là j'ai retrouvé toute mon attention en attendant justement le moment où la prof allait préciser un peu plus le sujet, voire corriger son erreur.

Ce qu'elle n'a pas fait, c'est donc bien ce qu'elle voulait dire, c'est donc un PEBKAC.

Attention que les membres de votre structure ne se suivent pas forcément en mémoire, car ils sont alignés sur des adresses paires

Je ne vois pas où est le pebkac. C'est même pour éviter ce phénomène qu'on rajoute __attribute__((packed)); à la fin de la définition de la structure.

Je ne remets pas en question l'alignement, j'ai eu suffisamment d'emmerde avec celui-ci.

En revanche selon mon professeur, l'alignement se fait obligatoirement sur 16 bits, d'où le PEBKAC.

Edit: Tiens le serveur n'est pas tout à fait à l'heure, décalage de trois minutes par rapport à la bonne heure ^^

Ah, ok, tu me rassures un peu. Donc sur un système 32 bits, un mot serait un DWORD alors que sur du 64 bits ce serait un QWORD...

Tout dépend de ton architecture. Mais pour répondre à ta question il y en a où c'est toujours valable.

Pour moi un mot c'est la taille de l'accumulateur du CPU. Soit la granularité minimal de calcul.
Le problème les x86-64, possèdes des instructions avec des mots de 16,32 et 64bits. Si on prend un mot minimal ce serait 16 et maxi 64 :/


Je dirais que ca dépend de ton architecture. Mais j'ai l'impression que pour le x86 le mot fait toujours 16bits.

C'est chaud tous ces pebkac de développeurs :/

Ben vi enfin l'été est là.

** Je suis loin ! **

Le stade ultime, c'est d'être une fille et de ne pas avoir de champoing. .

N'en dit pas plus, c'est effrayant :X

Je t'effraie ? Oh, qu'il est chou... <3 Invite moi demain soir (viens avec une bouteille de champoing).

J'y comprends rien. Je préfère téléphoner avec mes doigts.

Ok, je fais comment pour te phoner sur tes doigts ? :X

Original :
Je savais que c'était faux, mais je n'avais pas tilté au moment-même pour quelle raison: Ça n'était vrai qu'à l'époque des processeurs 16bits (Alignement sur 16bits, alias deux octets)."
Ça explique pourquoi il est formellement interdit d'utiliser des int dans le code, pour le type "bien plus économe" short.

L'actuel étant :
Je savais que c'était faux, mais je n'avais pas réalisé au moment même pour quelle raison : cela n'était vrai qu'à l'époque des processeurs 16 bits (alignement sur 16 bits, alias deux octets).
Ceci explique pourquoi il est formellement interdit d'utiliser des int dans le code, pour le type "bien plus économe" short.

Je n'ai pas le sentiment d'avoir modifié le sens de ta phrase :-/

Ah mea culpa, j'avais l'impression d'avoir plus précisé que ça.

Bon bah, j'essayerais de donner plus d'informations pour les prochains, ou de clarifier mes phrases :)

Mais très très rare quand même...

@Moot : tout dépend de ce que tu appelles rare. Je suis sur que t'en croises sans même t'en rendre compte XD.
Par contre effectivement peu de gens doivent les programmer. Vu que le paysage en France est le java et qu'il n'y a pas de jvm pour ce genre de chose.