Des entiers non signés

**Gruik** · 13/12/2006, 14h06

Boïnjouh,

Je trouve que c'est relou de taper "unsigned int"...
Est ce que c'est mal d'utiliser les types du genre "uint32_t"?
Ya t il plus court parmis les types du C?
Et je ne veux pas utiliser size_t pour autre chose que des tailles de zones memoire.

Merci

**Fabllot** · 13/12/2006, 14h14

Salut !

Envoyé par Gruik

Est ce que c'est mal d'utiliser les types du genre "uint32_t"?

A priori c'est la même chose puisque j'ai comme définition :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
typedef unsigned int uint32_t

Ya t il plus court parmis les types du C?

Y'a toujours la glib...
http://developer.gnome.org/doc/API/2...sic-Types.html

**Gruik** · 13/12/2006, 15h02

"typedef unsigned int uint32_t"
Bein oui, c'est ce qu'il ya dans <stdint.h> je crois, mais je sais pas si c'est standard ou quoi
..ou si je devrais faire mon propre typedef

**ronan99999** · 13/12/2006, 15h11

Tu peux utiliser unsigned tout seul, c'est la meme chose que unsigned int.

**koala01** · 13/12/2006, 15h18

Salut,

Entre l'auto-complétion et tout le reste, franchement, je ne vois que peu ce que tu trouve lourd à écrire "unsigned int"...

De plus, voyons les choses sous un autre angle:

Tu le dis toi meme, tu ignores si uint32_t est standard
ton EDI mettra les termes unsigned et int en évidence, mais fera-til pareil avec uint32_t
Tant qu'à faire, pourquoi ne pas systématiquement rajouter l'entete <GL/gl.h>(l'entete de base de OpenGl) pour pouvoir disposer de GLuint (c'est encore plus court à écrire que uint32_t... c'est pourquoi je pose la question )
es-tu sur que l'insertion de <stdint.h> et l'utilisation de uint32_t sera, au final, plus aisée que celle de unsigned int (hors les quelques secondes que tu gagneras peut etre à l'écriture)

Je n'ai pas de réponse toute faite à chacune de ces remarques, et je n'ai pas *forcément* d'avis préconçu sur la question (meme si je le donne plus loin)... Je suis donc ouvert à toute discution sur le sujet...

Mais, honnetement, j'ai l'impression que l'on atteind quelque part le sommum de la paresse (avec mon EDI, dés que j'ai écrit "unsi", j'ai l'auto-comptétion qui me propose "unsigned" comme seul choix) et qu'il *semble* domage de se passer de la "coloration synthaxique" qu'offrent les types clairement reconnus par l'EDI

**Gruik** · 13/12/2006, 15h27

Le coup de la coloration syntaxique, c'est vrai
Le coup des headers c'est pas un probleme dans mon cas puisqu'on inclut systematiquement un header tres general qui definit quelque macros et fait quelques inclusions
Je disais que c'est lourd à ecrire, mais je voulais dire que ça prend surtout beaucoup de place en texte alors que "int" est beaucoup plus petit. On ne devrait ecrire que "uint"...
Mais va pour "unsigned", j'ai juste peur que ça soit un peu choquant

Merci

**koala01** · 13/12/2006, 16h58

Je suis, pour tout dire, tres mitigé sur l'arguement "de la place que ca prend dans le code"...

Car ce problème peut tres facilement être résolu avec de bonnes habitudes/conventions de codages...

En effet, dans quelles circonstances va tu avoir besoin de "unsigned int"

Dans la déclaration de variable
dans le cadre d'un cast
dans le cadre d'une allocation dynamique
dans la déclaration des arguments/valeur de retour d'une fonction...

et pourtant:
la *bonne habitude* consiste à déclarer une variable par ligne.

C'est quand meme prendre un gros rique que de vouloir caster "brutalement" les choses... il est souvent préférable de les transtyper correctement.

un brol = malloc(sizeof(unsigned int)*10); ca prend pas tellement de place que ca (si tu commence à la colone 72 du fait de l'indentation, il est peut etre temps de penser un peu à factoriser tout le reste

)

Sur une fonction dont le prototype serait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

unsigned int ma_fonction_au_nom_interminable(unsigned int a, unsigned int b, unsigned int c, unsigned int d, unsigned int e, unsigned int f)

il y a trois manières d'arranger les choses:

La premiere, c'est qu'il faut bien se souvenir que plus un nom est long et complexe, plus le risque est grand de faire une erreur en l'écrivant, avec ou sans complétion automatique (et surtout sans, d'ailleurs)... il serait peut etre opportun de penser à un nom un peu plus court

La deuxième, c'est que trois à quatre arguments à passer semblent etre une limite à essayer de se fixer (au delà, non seulement l'appel a tendance à devenir illisible, mais, en plus, on court un risque beaucoup plus gros d'erreur en voulant passer les arguments)... Meme si dans l'exemple le risque est minimisé du fait que tous les arguments ont tous le meme type... mais les risques de fournir la mauvaise variable comme argument n°3 (passer mava, alors qu'il aurait fallu passer monentier... et que mavar était attendue en... 5eme position) devient, par contre bien plus important

Peut etre est-il temps d'envisager de créer une structure qui contienne ces 6 entiers non signés (allant d'un simple tableau à une structure plus importante)

La dernière possiblité, si les deux autres n'ont pas permis de réduire suffisemment l'espace pris par le prototype de la fonction, est qu'il est toujours possible d'aller à la ligne...

Cette fonction pourrait très bien s'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
unsigned int ma_fonction_au_nom_interminable(unsigned int a, unsigned int b,
                                             unsigned int c, unsigned int d,
                                             unsigned int e, unsigned int f)
/* ---- OU  ----OU  ---- OU  --- */
unsigned int ma_fonction_au_nom_interminable(unsigned int a,
                                             unsigned int b, 
                                             unsigned int c, 
                                             unsigned int d, 
                                             unsigned int e, 
                                             unsigned int f)
/* ---- OU  ----OU  ---- OU  --- */
(... il y en a tellement... )

**fearyourself** · 13/12/2006, 17h15

stdint.h est une extension C99, comme cela est bien expliqué ici :

http://nicolasj.developpez.com/articles/c99/#LV-A

Jc

**Gruik** · 13/12/2006, 17h17

Mon probleme de longueur de texte est effectivement dans le cas des paramètres de fonctions mais je connaissais le coup du sautage de ligne.
Je crois que c'était aussi le fait que le type soit coupé en 2 (selection plus difficile), mais on a le meme probleme avec les structs.
Je pense juste que ça devrait etre le plus simple possible vu comment l'utilisation d'entiers naturels est frequente.
Sans ça, on utilise "int" en lieu et place d'"unsigned int" et le compilo se plaint lorsqu'on compare un signé avec un non signé ou qu'on passe un int * à la place d'un unsigned int *

**Gruik** · 13/12/2006, 17h18

Envoyé par fearyourself

stdint.h est une extension C99, comme cela est bien expliqué ici :

http://nicolasj.developpez.com/articles/c99/#LV-A

Jc

Okay thanks

**koala01** · 13/12/2006, 17h29

Envoyé par fearyourself

stdint.h est une extension C99, comme cela est bien expliqué ici :

http://nicolasj.developpez.com/articles/c99/#LV-A

Jc

Merci pour l'info (personnellement, j'en savais trop rien

)

**koala01** · 13/12/2006, 17h47

Envoyé par Gruik

Mon probleme de longueur de texte est effectivement dans le cas des paramètres de fonctions mais je connaissais le coup du sautage de ligne.
Je crois que c'était aussi le fait que le type soit coupé en 2 (selection plus difficile), mais on a le meme probleme avec les structs.
Je pense juste que ça devrait etre le plus simple possible vu comment l'utilisation d'entiers naturels est frequente.
Sans ça, on utilise "int" en lieu et place d'"unsigned int" et le compilo se plaint lorsqu'on compare un signé avec un non signé ou qu'on passe un int * à la place d'un unsigned int *

En fait, la seule chose que tu ne puisse pas couper, ce sont les identifants (de type, de variable, de fonctions...) et les chaine de caractères...
des choses comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
unsi
gned int i; /* serait pour "unsigned int i;" */
char *machaine="bla 
bla"; /*serait pour "char *machaine="blabla;" */
i=Maf
onction(mac
haine); /* serait pour "i=Mafonction(machaine);" */

sont donc interdites

Sinon, dés que tu as une accolade, une parenthese, une ponctuation ou un opérateur mathématique,une indirection (ptr-> ou structure.) tu peux aller sans problème à la ligne, avec l'indentation qui te plait...

En fait, tu peux aller à la ligne et/ou mettre plusieurs espaces si cela te plait partout où tu peux décider de mettre un espace...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    unsigned int tab[10
                     *
                      3];
    unsigned
        int
        nombre;
    tab[5+
        3]=10;
    nombre=
        4*
        3+
        2;
    printf
        (
        "%d",
           nombre);

est donc tout à fait valide... bien que peu facilement lisible..., et correspond, tout simplement à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
unsigned int tab[10*3];/* ==unsigned int tab[30]:) */
unsigned int nombre;
tab[5+3]=10;
nombre=4*3+2;
printf("%d",nombre);

**Gruik** · 13/12/2006, 18h17

Oué je suis au courant, mais avoue qu'avoir 2 identificateurs au lieu d'un c'est chiant

**koala01** · 13/12/2006, 18h48

Envoyé par Gruik

Oué je suis au courant, mais avoue qu'avoir 2 identificateurs au lieu d'un c'est chiant

Ca, ca fait strictement partie de ton opinion personnelle, donc, je suis disposé à écouter ton argumentation sur le sujet, mais, de prime abord, je ne vois pas forcément ce que ca peut avoir de chiant...

**Médinoc** · 13/12/2006, 22h17

uint32_t n'est pas garanti être équivalent à unsigned int.
Si un int a une taille différente de 32 (sur certaines architectures 64bits, par exemple)...

Des entiers non signés

C

Discussions similaires

Partager

Partager