Version imprimable
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
Salut !
A priori c'est la même chose puisque j'ai comme définition :Citation:
Envoyé par Gruik
Code:
2
Y'a toujours la glib...Citation:
Ya t il plus court parmis les types du C?
http://developer.gnome.org/doc/API/2...sic-Types.html
"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
Tu peux utiliser unsigned tout seul, c'est la meme chose que unsigned int.
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 :question:
- 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:question: (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):question:
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 ;)
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
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":question:
- 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
il y a trois manières d'arranger les choses:Code: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)
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 :P
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) :question:
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:
2
3
4
5
6
7
8
9
10
11
12
stdint.h est une extension C99, comme cela est bien expliqué ici :
http://nicolasj.developpez.com/articles/c99/#LV-A
Jc
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 *
Okay thanksCitation:
Envoyé par fearyourself
Merci pour l'info (personnellement, j'en savais trop rien :oops:)Citation:
Envoyé par fearyourself
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...Citation:
Envoyé par Gruik
des choses comme
sont donc interditesCode:
2
3
4
5
6
7
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...
est donc tout à fait valide... bien que peu facilement lisible..., et correspond, tout simplement àCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17unsigned int tab[10 * 3]; unsigned int nombre; tab[5+ 3]=10; nombre= 4* 3+ 2; printf ( "%d", nombre);
Code:
2
3
4
5
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...Citation:
Envoyé par Gruik
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)...