Robot, capteurs et binaires: quel foutoir!

International Français
33

68tjs:
Je répondais à la remarque générale :
C'est ce qui m'a fait conclure qu'un grand nombre de développeurs inconnus en restent aux définitions du début du C et ne suivent pas et ne sont pas intéressés par les évolutions.

Qu'en tant que professionnel on ne se précipite pas sur la dernière évolution qui vient de sortir je le conçois aisément mais qu'on en reste à la norme du début des années 1970 c'est quand même une attitude bizarre pour un développeur.

l'avantage et l'inconvénient de ces types est de fixer la taille mémoire allouée. Dans certains cas c'est bien, dans d'autres moins bien. Quand vous n'avez pas de raison valable de figer les choses, il peut être bien de ne pas le faire.

Un exemple : vous vous souvenez du bug de l'an 2000... En fait on appelle cela un bug mais c'est une erreur de conception systémique - les informaticiens avaient figé dans le marbre le nombre de digits pour une représentation (2 caractères en base 10 pour représenter l'année 19xx on ne conservait que xx) ce qui fait que le code n'a pas évolué avec les machines... A l'époque chaque octet comptait et quand vous faisiez de la comptabilité et avez besoin de stocker énormément de dates en format lisible, gagner 2 octets à chaque coup c'était énorme... Personne n'avait pensé que ce code durerait jusqu'en 2000 cependant....

Il en va de même pour "le bug de l'an 2038" qui pourrait perturber le fonctionnement d'un grand nombre de systèmes informatiques le 19 janvier 2038 --> les ordinateurs qui codent en dur le temps sur 32 bits signé afficheront alors la date du 13 décembre 1901 et ce ne sera que plus tard pour les ordinateurs utilisant un non signé sur 32 bits uint32_t (en 2106)..

La norme définit pourtant time_t comme étant le type à utiliser pour représenter le temps (et la norme ne définit pas sa taille). Si tout le monde l'avait fait il suffirait de passer time_t en 64 bits et en recompilant sur de nouvelles architectures on repousserait le problème jusqu'au 4 décembre de l'an 292277026596... soit plus de 20 fois l'âge de l'Univers...

Mais voilà au lieu de time_t on utilise unsigned long or uint32_t pour les opérations sur le temps... et les vieux programmes qui vont passer sur de nouvelles architectures potentiellement 64 bits vont rester coincé sur 32 bits...

--> faites vous uint32_t chrono = millis();ou

#include <time.h>
...
time_t chrono = millis();

-->idéalement il faudrait faire le second...