Discussion :

[DLOYAS]

salut,

c'est quoi la diffèrence entre unsigned int et int ?
le fait de declarer une date avec le type unsigned int est il correcte ?

[Daïmanu]

Bonjour.

int (ou signed int) est un entier signé, dont la valeur peut être négative, positive ou nulle.
unsigned int est un entier non signé, c'est-à-dire dont les valeurs ne peuvent être que positive ou nulle.

le fait de declarer une date avec le type unsigned int est il correcte ?

Oui, mais généralement on utilise des bibliothèques pour ça (comme la biblothèque standard).

[Sve@r]

c'est quoi la diffèrence entre unsigned int et int ?

Salut

En mémoire il n'y en a aucune. C'est juste une indication permettant à ton compilo de comprendre comment interpréter un nombre dont le premier bit est à 1 (est-ce que ce bit entre en jeu dans la valeur du nombre ou bien signifie-t-il que c'est un nombre négatif).
Ca peut avoir un impact en termes de performances quand une variable est copiée dans une variable plus large. Par exemple prenons une variable sur 8 bits (char ou unsigned char) et avec la valeur 0x80 (1000 0000 en binaire) stockée à l'intérieur. Si cette variable est recopiée dans un short (16 bits) alors

• si c'est un unsigned char, le short contiendra alors 0x0080 (0000 0000 1000 0000 en binaire)
• si c'est un signed char, le short contiendra alors 0xFF80 (1111 1111 1000 0000 en binaire)

Hé oui, pour garder le bit de signe, la recopie l'étend sur toute la plage disponible (extension du bit de signe) et cette recopie prend forcément plus de temps que si on n'a pas à gérer le signe...

le fait de declarer une date avec le type unsigned int est il correcte ?

Correct ou incorrect (sans "e") au-moins ça montre que tu réfléchis sur la plage des valeurs possibles de ton programme et rien que ça c'est déjà appréciable. Toutefois tu n'as pas réfléchi assez longtemps car, en dehors de bibliothèques dédiées que tu n'es pas forcé de connaitre, à moins que tu ne veuilles gérer des dates d'ici jusqu'à la mort du soleil, un unsigned short suffit...

[grim7reaper]

Hé oui, pour garder le bit de signe, la recopie l'étend sur toute la plage disponible (extension du bit de signe) et cette recopie prend forcément plus de temps que si on n'a pas à gérer le signe...

Comme cette extension du bit de signe est fait par le hardware, la différence (s’il y en a une) est plus que négligeable (je serais curieux de voir comment tu arrives à le mesurer).
Il y a des choses bien plus problématique entre signed et unsigned.
Du genre l’overflow sur un unsigned c’est parfaitement défini, mais sur un signed c’est un undefined behavior.

à moins que tu ne veuilles gérer des dates d'ici jusqu'à la mort du soleil, un unsigned short suffit...

Mouais, ou pas…
Tout dépend de comment est représenté la date : en prenant un timestamp à la Unix, 32-bit signé ne t’amène qu’en 2038 (et on part de 1970 pourtant).

[Sve@r]

Comme cette extension du bit de signe est fait par le hardware, la différence (s’il y en a une) est plus que négligeable (je serais curieux de voir comment tu arrives à le mesurer).

Pourquoi la mesurer ? Je sais qu'une opération prend obligatoirement plus de temps qu'une "non opération". A partir de là, si mon programme évite les opérations inutiles je ne m'en porte que mieux.

Et le terme "plus que négligeable" dépend du besoin. Pour celui qui va calculer les éphémérides du jour de sa naissance ce sera effectivement probablement pas super capital mais pour celui qui est dans son avion et dont le calculateur est en train de vérifier si l'onde radar qu'il a intercepté est juste un radar météo ou si c'est un radar plus sérieux qui contrôle une batterie de missiles sol-air, il risque de ne pas être du même avis...

Il y a des choses bien plus problématique entre signed et unsigned.

Sûrement qu'il y en a. J'en ai juste évoquée une que je connaissais. Mais le fait qu'il y en a d'autres serait-il une raison pour taire celle-là ?

Tout dépend de comment est représenté la date : en prenant un timestamp à la Unix, 32-bit signé ne t’amène qu’en 2038 (et on part de 1970 pourtant).

Parce que le timestamp Unix gère toute la date seconde par seconde sur un unique long. J'avais plutôt en-tête une structure bateau à la "jj-mm-aaaa" telle qu'on en voit dans les TP donnés aux étudiants.
Ceci dit, le futur timestamp gèrera toujours la date seconde par seconde mais ce sera sur du 64-bits signés. Je te laisse mesurer la durée que ça te donnera

[grim7reaper]

Pourquoi la mesurer ? Je sais qu'une opération prend obligatoirement plus de temps qu'une "non opération". A partir de là, si mon programme évite les opérations inutiles je ne m'en porte que mieux.

Et non, c’est pas si simple. Un exemple classique parmi d’autres…
Donc comment tu sais qu’il y a une différence ? As tu pu la quantifier ? Sur quelle architecture de processeur ?
Clairement, sur du x86 ou x86-64 je serais surpris qu’il y ai une différence mesurable (si différence il y a) sur de l’extension de bit (du moins sur du 32 et 64 bits, en SSE peut-être (et encore)).

Et le terme "plus que négligeable" dépend du besoin. Pour celui qui va calculer les éphémérides du jour de sa naissance ce sera effectivement probablement pas super capital mais pour celui qui est dans son avion et dont le calculateur est en train de vérifier si l'onde radar qu'il a intercepté est juste un radar météo ou si c'est un radar plus sérieux qui contrôle une batterie de missiles sol-air, il risque de ne pas être du même avis...

Là pour le coup je doute que ça soit non négligeable pour n’importe quelle application, sauf si c’est mal géré par le hardware auxquel cas OK je veux bien.
Encore une fois, tu as des mesures ? Et sur quelle archi’ ?

Sûrement qu'il y en a. J'en ai juste évoquée une que je connaissais. Mais le fait qu'il y en a d'autres serait-il une raison pour taire celle-là ?

Nope, c’est bien de la signaler. Mais c’est mineur.
Surtout que l’extension du bit de signe n’est pas garanti par le standard (genre sur du complement à un tu n’as pas de bit de signe, et le C ne garantit pas l’usage du complément à deux). Mais je te l’accorde, en pratique on bosse quasi-exclusivement sur du complément à deux.

J'avais plutôt en-tête une structure bateau à la "jj-mm-aaaa" telle qu'on en voit dans les TP donnés aux étudiants.

C’est pour ça que j’ai fait ma remarque car tu ne précisais pas que tu parlais de représenter le temps comme une structure, du coup ton affirmation était fausse sans cette hypothèse préalable.