Reprise du message précédent :
http://forum.hardware.fr/hardwaref [...] 8490-1.htm
No comments.

size_t = unsigned. Qu'est-ce qu'un vébéteux ?

un mec qui code en VB

sous turbo C, size_t c'est un unsigned ?
 
j'ai aucune moyen de verifier mais deja que les int sont sur 16 bits...
 
pour moi ca serais plutot un unsigned long

on ne compte plus les architectures où size_t est un long unsigned. unsigned n'est censé collé à rien du tout. Classiquement, on trouve sizeof(void*) == sizeof(long) et size_t de la même taille. La portabilité tu nous en parle ? la première chose à considérer, c'est de ne pas faire des prédictions foireuses sur la taille en octets. Réveille-toi, y a pas que le x86-32bits dans la vie.
 
le reste de ton blabla ... ça vaut pas un clou. C'est parce que t'as de mauvaises habitudes et que tu es incapable de bien utiliser le mot-clef const et size_t qu'il faut que les débutants fassent de même. D'ailleurs tu crois qu'ils ont quelle opinion d'un mec qui frime mais qui n'est pas capable de conceptualiser le type size_t ?
 

faux. c'est dépendant de ta plateforme. et quand bien même ça serait égal, size_t a une sémantique que n'a pas un unsigned.

Juste pour ma culture à une question que je ne me suis jamais posé : qu'elle est la sémantique de size_t ?

Merci
 
Je me disais que c'était dommage et peu évolutif de ne faire que quelques vérifs aussi ciblées (tous impairs, tous égaux, etc) et j'avais un peu envie de m'éclater à faire un exercice où on pourrait revenir plus tard pour définir quelles vérifs on fait sur les 3 nombres.
 
J'avais en plus essayé de faire aussi "propre" que Taz le souhaite mais j'ai pas réussi
En tout cas cela a déclanché une méga polémique...

J'en ai plus que marre de me défendre sur des détails. Vous n'avez toujours pas compris l'idée que je voulais faire passer. Me répéter encore est inutile...
 
C'est uniquement pour votre culture :

Désolé les gars : perdu !
Dans le monde 16 bits, on a : sizeof(int) == sizeof(size_t) == WORD == 2
(je vais vous faire mal : sizeof(void *) == 2 OU 4 !, dépend d'options de compile)
Dans le monde 32 bits, on a : sizeof(int) == sizeof(size_t) == DWORD == 4
Et dans le monde 64 bits on aura : sizeof(int) > sizeof(long)
 

Fun ! Dire ça à un gars qui a fait des années de developpement sous DOS ! Maintenant, c'est vrai que le portage Windows prend pas mal de mon temps. Je ferais l'effort de me rappeler ton conseil.

allez casse-toi ...
 
si t'avais un peu d'estime pour toi même, t'aurais pris la peine de lire la dernière révision juste au cas où ... ils parleraient de size_t ...

lsdyoyo tu ne sais manifestement pas de quoi tu parles. Dans le "monde 64 bits" (et encore faut savoir de quoi on parle) on aura generalement sizeof(long) == 64 et sizeof(int) = 32. Quant a dire WORD == 2, ca aussi c'est faux. Un mot c'est la quantite naturellement manipulee par une architecture (et encore), et ca depend donc de l'architecture.

sizeof(long) == 64  
 
 
tu l'a payée combien ta bécane 512bits ?

Ouais bon tout le monde a compris

  up

size_t est le type de la variable qui stocke la taille d'un fichier dans la structure "stat" (voir dans "/usr/include/sys/stat.h" ).
Cette structure "stat" est utilisée pour récupérer les informations d'un fichier (propriétaire, droits, nb de liens, taille, etc) sous Unix Cette structure possède un membre "st_size" de type "size_t"
size pour taille
t pour type

rien à voir avec stat .... faut tout de dire à toi
 
 
size_t c'est le type de retour de l'opérateur sizeof. C'est donc un type tout indiquée pour exprimer une quantité de 'byte'. On le retrouve donc comme argument de malloc, fread, etc

D'autant que st_size dans struct stat est de type off_t

Pas partout, et surtout pas dans la norme POSIX...http://www.jaluna.com/doc/c5/html/ [...] posix.html
 

Ben tu sais, les trucs que tu dis toi ne sont pas toujours vrais. Notemment quand j'ai demandé si "fpurge" existait (http://forum.hardware.fr/hardwaref [...] tm#t817589) tu as répondu avec la morgue qui te caractérise "ça n'existe pas" (http://forum.hardware.fr/hardwaref [...] tm#t817590)
 
Alors va donc voir là http://www.epita.fr/docs/man3/fpurge.3.html puis ensuite peut-être que tu te mettras à réfléchir à ce que les autres disent avant de les envoyer bouler.. surtout que certains autres ne sont pas que sous C++Builder ni que sous du Linux !!!

attention fpurge c'est pas standard, c'est meme indiqué sur ton lien
 
donc à oublier
 
c'est comme les fflush de vs qui ont un effet déterminé sur <input stream>, apres quand tu portes le code ca peux faire planter
 
et puis la logique c'est de lire ce qu'on saisie

 
Vivi, tu as raison. "fpurge" ou "__fpurge (sous Linux)" n'est pas une bonne idée je sais. Mais l'idée du post précédent était de bien faire comprendre que les remarques de Taz (même si c'est ton copain) ne sont pas forcément les meilleures et qu'il ne sait pas tout...

Taz code en C/C++ standard, donc pour lui quand une fonction (fpurge) ne fait pas partie des standards ou d'une lib bien précise non restreinte à un compilateur unique elle n'existe pas  
Et ca se comprend

Si : je sais à qui je parle, et que quand on est étudiant, on travaille sur des plateformes hétérogènes et qu'on a aucune idée de ses futures emplois. Je sais aussi que respecter une norme c'est une bonne exercice de style, très payant.
 
Quant à ton exemple de fpurge, quand tu lis la doc, tu vois que fpurge est sous BSD et que Linux fournit un __fpurge ...
 
Quand c'est faisable en standard, il faut le faire en standard. Peut-être que tu es loin des considérations de portabilité, mais moi je code un truc, il faut qu'il marche sur Linux, BSD, Solaris, AIX ou même windows
 
un truc avec un double _ en préfixe, je veux même pas en entendre parler, il vaut mieux faire comme si ça n'existait pas.

heu.. au risque de m'incruster comme un poulpe sur la soupe...
 
voilà ce que dit la norme ansi :
La taille d'un char est de 1 octet.
 
char  
 caractère  -128  127  1  
 
short  
 entier court  -32768  32767  2  
 
int  
 entier standard  -32768  32767  2 ou 4
 
long  
 entier long  -2147483648  2147483647  4  
 
Maintenant à partir du moment où on utilise ça le problème de portabilité est faible.
 
Je bosse sur une appli dépassant le 500k lignes écrite à l'origine pour unix, elle tourne aujourd'hui sous windows sans prob maj.
Les prob de portabilités ne venaient pas de là en tout cas.

heuuu t'as pas un peu mis des = à la place des <?
 
non parce que short = int = long = non signé...

 
et taz il m'a déjà grondé parce que la taille d'un char peut être différent d'1 octet

oui, char = 1 byte et il est sous entendu que c'est pas forcement 8 bits

 
Signé ou non ça fait la même taille. Les valeures sont définies comme telle par la norme ansi.
 
Après rien n'empêche de revoir l'implémentation éffectivement.
 
Mais l'intérêt de suivre la norme, c'est la portabilité justement.

non mais là le problème c'est que t'as écrit texto "short = long"

 
Si pour la norme ansi c'est 1 octet.

 
mea culpa j'ai fait un copier coller:D...
 
short = 2 octets of course.
 
y'a pas besoin de se prendre la tête avec les size_t, si on sait qu'on va dépasser 65535, on déclare un long int et c'est réglé.

 
moi je parle de c89 plus communement appelé c ansi
 
 

 
??
 
mais c'est justement pour  ne pas avoir a te prendre la tete !

justement non, et c'est là dessus que taz m'a engueulé la dernière fois: la norme d'impose pas l'implémentation, elle impose des valeurs qui doivent obligatoirement être gérables par toutes les implémentations
 

(tiré de cet article)
(ca doit aussi imposer des relations d'ordres genre char <= short <= int <= long, mais je les trouve pas dans l'article)
 
donc d'après cette norme rien ne t'empêche de faire des chars sur 32 bits

   
il suffit de TOUJOURS utiliser size_t et le problème est rêglé, ca permet à tout le monde de reprendre le code et le jour ou ta range va changer (genre qu'il faudra justment gérer des valeurs au dessus de 65535) ca n'aura aucune importance

Ce sont des valeures minimum, donc tu es sûr d'avoir au moins ces conditions, le problème de portabilité est donc réduit...

ouais, ouais, fait pas le gentil, tu as parjuré les saintes écritures, personne ne l'oublie

C'est là le problème ! Taz engueule beaucoup de monde et beaucoup de monde se laisse engueuler par cet ersatz de Roi Soleil sans réagir...
 

Je suis peut-être naïf mais je suis étonné que "sizeof()" qui est un opérateur du C et qui est donc codé en natif dans le langage au même titre que d'autres opérateurs ("+", "-", "++, "%", "&&" etc) donne comme résultat une valeur de type "size_t" alors que le type "size_t" n'est pas natif du langage...
 
Contrairement à ce que tu dis, Taz, ces deux pages http://publications.gbdirect.co.uk [...] alloc.html et http://www.lri.fr/~aze/page_c/aide_c/sizeof.html disent que "sizeof()" est "unsigned int"
 
Evidemment, ceux qui ont écrits ces pages peuvent se tromper. Mais dès demain j'essaierai un "man sizeof" sur les différents systèmes que j'utilise...

size_t c'est un alias d'un type natif, comme ptrdiff_t, ca reviens au meme ?

 
J'en sais vraiment rien !

ben c'est lapremiere question à se poser
 
et pour les liens ca peut etre des erreurs, on ne compte plus les mythes à ce sujet
 
size_t est le type retour de l'operateur sizeof, c'est un entier non signé

le truc, c'est qu'à chaque fois que j'ai mangé dans ma gueule (ou presque) de la part de taz c'était à raison  
et quand je m'aperçois qu'il se plante (mauvaise interprétation/il va trop loin/manque de chocolat/manque de sexe/autre), ben je lui dit

bla bla bla, t'en as pas marre de raconter n'importe quoi ? tu te décides quand à lire le K&R ou le dernier brouillon du WG14 ? Moi je ne dis rien, je répète. Maintenant si toi tu marches au 'je trouve, donc c'est vrai' ...