Un séisme cataclysmique fait trembler jusqu'aux fondations du web et ébranle tout le monde connu, les réseaux sociaux sont en feu, Stroustrup refuse de répondre au téléphone, tandis que nous attendons impatiemment une déclaration de nos dirigeants éclairés : le über geek JF Bastien vient de publier une proposition de changement du standard C++ décrétant qu'il y aurait exactement 8 bits dans un byte, prouvant au passage que les français étaient une fois de plus précurseurs en généralisant le terme octet.
Alors vous le savez sans doute, une immense majorité des architectures aujourd'hui font effectivement ce choix, et les compilos modernes sont construits sur ce modèle. L'argument de JF Bastien est donc que non seulement il n'existe presque plus de systèmes où ce n'est pas vrai, mais qu'en plus la minorité de développeurs qui pourraient travailler sur ces architectures n'ont aucun besoin d'un compilateur C++ moderne: "The question isn’t whether there are still architectures where bytes aren’t 8-bits (there are!) but whether these care about modern C++… and whether modern C++ cares about them."
Je sens confusément que je devrais avoir une opinion tranchée sur la question, il ne me reste plus qu'à déterminer laquelle.
# Mauvaise idée ?
Posté par Walter5 . Évalué à 2 (+2/-0).
Celui qui a fait cette proposition parle de la situation présente avec une majorité d'architectures qui codent sur 8 bits, mais il ne semble pas regarder vers le futur.
Dans le futur, on aura peut-être besoin d'octets plus gros, par exemple 10 bits. Les nouveaux écrans codent déjà les couleurs sur 10 bits au lieu de 8.
Donc figer la taille d'un octet à 8 bits, c'est peut-être une mauvaise idée.
[^] # Re: Mauvaise idée ?
Posté par Meku (site web personnel) . Évalué à 4 (+2/-0).
Oui alors faudra pas appeler ça un octet. Les mots ont un sens.
[^] # Re: Mauvaise idée ?
Posté par Zenitram (site web personnel) . Évalué à 2 (+1/-1). Dernière modification le 19 octobre 2024 à 13:22.
Walter5 a juste mal traduit et confondu byte et octet, et le je parle français à 100% ou anglais à 100%.
https://fr.wikipedia.org/wiki/Byte
https://fr.wikipedia.org/wiki/Octet
https://en.wikipedia.org/wiki/Byte
https://en.wikipedia.org/wiki/Octet_(computing)
Le byte (ou multiplet) peut être plus gros ou plus petit (juste > 1, mais de tête dans le standard la taille minimum d'un byte est 8), jamais l'octet (taille fixe).
Walter5, tu n'aides pas!
[^] # Re: Mauvaise idée ?
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
La question n'est pas de savoir si un jour on va devoir traiter des données plus grandes, mais est-ce qu'un jour est-ce que les machines qui adressent au minimum 8bits ne seront plus hégémoniques.
Perso j'en sais rien et je dois avouer, je m'en fou un peu
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvaise idée ?
Posté par cg . Évalué à 2 (+0/-0).
Je me demande quel tête ou quelle taille peut bien avoir un octet (enfin un char, vous comprenez quoi :D) sur un ordinateur quantique.
[^] # Re: Mauvaise idée ?
Posté par Pol' uX (site web personnel) . Évalué à 5 (+3/-0).
Le jour où un octet ne fera plus 8 bits, le monde ira encore plus mal.
Adhérer à l'April, ça vous tente ?
[^] # Re: Mauvaise idée ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
La Suisse pourrait décider de lancer des huitets à la place ? Les réseaux sociaux pourraient avoir un oktet, un booléen indiquant si t'es ok ou pas ou autre ? On aura des octets utilisant deux syllabes, une petite et une grande, respectivement de 3,5 et 4,5 bits ?
(Sérendipité : Un octet est une couche électronique d’atome comprenant huit électrons.)
[^] # Re: Mauvaise idée ?
Posté par Thomas Douillard . Évalué à 3 (+0/-0).
Si on compte les bits en octets, il semble cohérent de nommer les qbits en qoctets.
[^] # Re: Mauvaise idée ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 19 octobre 2024 à 18:03.
Dans le Seigneur des Anneaux, la Communauté compte un demi hobtet.
(j'ai honte, pardon aux personnes résidents dans la Comté)
# Question probablement bête
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Quelqu'un peut expliquer le rapport entre char et octet ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Question probablement bête
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Actuellement il n'y en a pas vraiment. En C et en C++, on définit que sizeof(char) vaut 1. Quand on incrémente un pointeur sur un char, il s'incrémente donc de 1. Il est impossible d'avoir un type de données plus petit (sauf les booléens et les bitfields), et les types plus gros sont des multiples de la taille d'un char. Mais, on peut implémenter le C et le C++ avec n'importe quel nombre de bits dans un char.
Il existe quelques architectures incapables d'adresser la mémoire plus finement que 16 ou même 32 octets. En particulier: des machines dont le jeu d'instruction n'est pas un lointain descendant du PDP-11; et certaines familles de DSP conçus par exemple pour le traitement du son en 16 bit.
Pour aaoir récement implémenté un compilateur C sur une telle architecture, je confirme qu'il a été relativement difficile de trouver une chaîne d'outils capable de prendre cela en compte (mais j'ai finalement convaincu les développeurs de vbgc et de vasm de se pencher sur le problème). Je regrette de ne pas pouvoir faire de C++ sur ce système pour l'instant, c'est un langage intéressant pour réaliser de nombreuses optimisations à la compilation qui me seraient bien utiles,
[^] # Re: Question probablement bête
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Je posais la question car l'auteur de la proposition a l'air de considérer évident et implicite (dès le titre) que char et byte c'est la même chose, alors que ça pourrait me semble à étayer dans un doc de normalisation. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Question probablement bête
Posté par AncalagonTotof . Évalué à 2 (+2/-1).
Alors, je serais vous, je vérifierais systématiquement que
sizeof(char) == 1
.Retour quasi 10 ans en arrière. R&D pour le développement d'une enceinte Bluetooth.
Est-ce qu'on pourrait faire tout avec la puce à la mode à l'époque, à savoir, la
CSR 8670
?NB: CSR est une boîte anglaise spécialisée dans ce genre de puce. Était, puisque rachetée par Qualcomm en 2015.
Globalement : non, pas possible. Mais il a fallu passer quelques mois pour prendre la mesure de la perfidie des grands bretons. Sur le papier, elle est géniale cette puce : en plus du Bluetooth évidemment, un MCU accompagné de son DSP, trop cool.
En pratique … Énormément de pipo des commerciaux et technico-commerciaux …
Outre les limitations de ressources hallucinantes, les limites très mal documentées de l'unique fonction pour communiquer sur le bus I2C, après quelques bizarreries, j'ai fini par afficher la valeur de
sizeof(uin8_t)
.Réponse :
2
.Oui,
2
.Le support a été incapable de m'expliquer pourquoi.
J'ai trouvé la réponse seul, par hasard, sur le forum concernant une autre de leurs puces.
Réponse : c'est légal, c'est autorisé par la norme C, un octet ne fait pas forcément 8 bits.
OK. Pour l'I2C en particulier, c'était déjà la merˆWpanade, alors transférer de la data stockée dans un tableau dont on ignore comment seront traités les "trous" …
Et quid de l'arithmétique des pointeurs ? Il avance de 1 ou de 2 quand je fais
++
? Pour coller ausizeof
, ce serait 2. Pour revenir à cette fonction de transfert sur l'I2C : est-ce que les "trous" sont transférés ? Est-ce que je dois plutôt gérer un tableau de uint16_t ? Quid de l'endianess ?…Cette épée de Damoclès en permanance sur ce qui se passe au plus bas niveau … Stressant …
Je vous raconte pas les nœuds au cerveau et le doute permanent sur le comportement du chip.
Conclusion : le gars qui customise un compilo pour en arriver là, c'est le diable en personne !
À moins que quelqu'un connaisse un cas de figure où c'est justifié ? Est-ce que c'est plus répendu que je ne le pense ?
Non, récupérer apacher une vieille architecture moisie des années 80s n'est pas une excuse acceptable !
[^] # Re: Question probablement bête
Posté par Zenitram (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 19 octobre 2024 à 13:54.
Alors une chose de sûr, un octet fait forcément 8 bits, c'est sa définition, dans un dico et tout et tout (octet, et du latin), j'imagine donc que tu voulais parler d'une byte ou multiplet
Ensuite, la j'aimerai l'argument, qu'on me corrige si je me trompe mais il me semble que le standard dit que :
uint8_t fait exactement 8 bit
sizeof(char) fait forcément 1
la taille minimum de char est 8
Partant de ces postulats, mathématiquement sizeof(uint8_t) ne peut pas être autre chose que 1 (aucune taille de char, la seule chose variable, peut faire une autre valeur sans manquer de respecter une des règles, genre il faudrait que la taille d'un char soit 4 qui n'est pas valide).
Clairement, et on peut supposer que c'est un gros bug mais qu'ils ne veulent pas corriger à cause de conséquences chiantes à gérer.
[^] # Re: Question probablement bête
Posté par AncalagonTotof . Évalué à 1 (+0/-0).
1) la définition du dico n'est pas celle de la norme je pense
2) je suis d'accord, on ne sait plus où on habite si
sizeof(uint8_t) != 1
,...16... != 2
, etc3) je "garantie sur facture" que j'ai vu et contrôlé de mes yeux vu un sizeof(uint8_t) --> 2; et que d'après les références pointées à l'époque sur le forum CSR, la norme l'autorise. Ça n'était pas un bug.
Mais bon, je parle de norme sans la connaître, étant plus du genre empirique. Si quelqu'un ici l'a lue et sait retrouver la référence précise que j'ai pu lire à l'époque, merci d'avance.
Ceci dit, ma mémoire peut me jouer des tours, plus souvent que je ne le pense, mais j'ai retrouvé un bout de conversation que j'ai eu avec les potes, tellement j'étais surleculté par cette mauvaise surprise. J'avais les idées fraiches à l'époque, et donc, je venais tout juste d'expérimenter ça :
[^] # Re: Question probablement bête
Posté par Zenitram (site web personnel) . Évalué à 2 (+0/-0).
La il va falloir me confirmer que la norme utilise le mot "octet", vu le sujet du journal j'ai un gros doute, je suis prêt à tenir un pari avec enjeux avec toi sur byte.
Voila :)
Le norme est claire : char n'est pas uint8_t, et char a minimum 8 bits, ça implique pas forcément 8, et donc oui un unsigned char peut avoir une valeur supérieure à 255, rien d'anormal, juste pas courant de nos jours sans que la spec ne l'interdise, du moment pour le moins (d'où le sujet du journal).
# J'hésite
Posté par Julien Jorge (site web personnel) . Évalué à 9 (+7/-0).
Aucun doute qu'en dehors de quelques architectures exotiques on aura 8 bits dans un
char
. Néanmoins, comme pour trop de nouveautés du C++ de ces dix dernières années, je me demande quel problème ce papier essaye de résoudre.Sans doute. Des exemples peut-être ? Histoire qu'on puisse juger de cette charge ajoutée.
Oui ce n'est pas moderne, mais faut-il jeter tout ce qui n'est pas moderne ? Le C++ n'est pas un langage moderne de toute façon.
Et ? Les nouveaux programmeurs on en effet tout à apprendre du langage et de son histoire.
Un peu de temps perdu pour quelques programmeurs. Okay, pas vraiment un problème mais pourquoi pas.
Avec un lien vers un tweet. Bon, un type sur Internet trouve le langage idiot. Qui ça intéresse ?
À mon humble avis le comité passe beaucoup trop de temps à essayer de se convaincre que ce langage n'est pas dépassé. On peut mettre autant de qualificatifs modern ou contemporary à côté de son nom, le C++ est factuellement un langage de vieux. La plupart des programmes écrits en C++ sont de vieux trucs, et c'est normal vu son âge. Si vous voulez un langage moderne et performant il y a d'autres candidats plus pertinents.
L'argument de l'attention aux jeunes programmeur est fallacieux. Chaque couche de modernisation est une chose supplémentaire à comprendre pour les devs C++.
[^] # Re: J'hésite
Posté par Walter5 . Évalué à 3 (+4/-1).
En quoi le C++ serait dépassé ?
C'est un langage vieux, et alors ?
Quel est l'intérêt d'utiliser un langage apparu récemment ?
Et quels sont les langages performants plus pertinents que le C++ ?
[^] # Re: J'hésite
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Il est de plus en plus lourd et complexe. Il est pas sécurisé (du moins pas au top). Ses spécification sont fermées…
Il n'est pas ce qui se fait de mieux.
Plus de sécurité, plus de performances, plus de productivité…
Le Rust de toutes évidence.
PS: Tu troll un peu alors désolé de troller un peu aussi… Mais mon avis est quand même que Rust est supérieur à C++ sur à peu près tout les points. Reste un point pour C/C++ les bases de codes sont énormes, on doit les maintenir, on doit faire évoluer le C/C++, mais clairement c'est un boulet à trainer (Et c'est normal).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Fortran
Posté par vmagnin (site web personnel) . Évalué à 4 (+2/-0).
Sur les 681 pages de la norme Fortran 2023, le mot byte n'apparaît que dans la section consacrée à l'interopérabilité avec le C. Le mot octet apparaît deux fois.
Le FORTRAN est né avant que le byte se stabilise sur 8 bits, d'où cette prudence qui peut bien sûr être parfois gênante quand on vit dans les systèmes actuels. Le module intrinsèque
iso_fortran_env
, introduit avec Fortran 2008, définit néanmoins un KINDINT8
pour lesINTEGER
.Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.