Reprise du message précédent :

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' ...

et ça rentre bien d'ailleurs
 

aucun problème. Si je me plante, je le reconnais et je suis content d'admettre mon erreur. Maintenant quand je raconte des trucs, je vérifie toujours. Je fais pas au feeling ou à coup de google

 
Nul n'est parfait.

 
Peut être, mais ce qui prévaut aujourd'hui c'est le C99 non?

ça dépend de tes contraintes. Mais là je vois pas trop le rapport. Sauf exception, il me semble que le C99 est compatible avec les normes précédentes : ce qui est vrai pour l'ANSI s'applique donc également.
 
Vérification faite, le C99 ne contredit aucun point concernant <limits.h>

Si tu avais au moins lu en entier la premiere page que tu donnes en lien au lieu apparement de la survoler histoire de contredire Taz, tu aurais trouvé ceci:
 

 
A+,

gilou tu rox

bien bu      

 
Je vais traduire parce qu'apparemment, tu ne lis pas bien l'anglais...
Quel est le type qu'a sizeof ? la réponse est que c'est défini dans l'implémentation et sera et que ce sera unsigned int ou unsigned long et cela dépend de votre implémentation (ndt je ne vois pas pour le moment que "sizeof" est de type "size_t" )
Il y a deux choses sûres à faire: transformez votre valeur de retour en "unsigned long" ou en "size_t" fourni dans le fichier d'en-têtes <stddef.h>. Par exemple (suivi du code source)
 
Pour moi, ce texte ne dit pas que sizeof est du type "size_t" (comme le dit Taz), juste qu'il faut, si on veut être 100% portable, caster son retour en "unsigned long" ou en "size_t". Je n'ai jamais nié ce dernier fait (zavez qu'à relire mes posts) mais je rappelle quand-même qu'il s'agissait au départ d'aider un débutant à trouver des algo pour répondre à un exercice simple, pas de faire un code 100% portable. Taz le merveilleux est ensuite arrivé en disant que c'était pas terrible (comme d'hab) et voilà où on en est.
 
gilou t'as roxé !!!
 

ratai, ca dit que pour être sur il faut:
1- soit caster en unsigned long, dans la mesure ou le retour est soit unsigned int soit unsigned long
2- soit utiliser size_t, directement (pas caster) [parce que size_t est le type de retour de sizeof]
 
Donc pour faire du code portable, simple et compréhensible, il faut utiliser size_t
(par ailleurs size_t est utilisé partout dans la STL par exemple)

ouais allez rattrape toi aux branches, planque toi derrière une traduction.
 
Bon je te le fais en français, extrait du K&R, première référence à sizeof dans le texte
"size_t est le type entier non-signé retourné par l'opérateur sizeof". On trouve la même définition dans tous les papiers du WG14.
 
Et à lire toute la documentation officielle, je n'ai rien vu qui interdisse à size_t d'être un short ou un long long. Tout ce que je vois, c'est que ce doit être un entier unsigned. Je pense d'ailleurs qu'il existe des implémentation ou size_t est un llu, en effet, sur certaines plateformes 64bits ne sont pas sur le modèle long pointer, mais long long pointer.

 
+1
 
Sve@r > relis bien ! soit tu cast en unsigned long par securité, soit tu utilise size_t qui est le type adequate
 
c'est ce qu'il  fallait comprendre, maintenant à ce que ca soit juste pour les types retour...
 
size_t est le type retour de sizeof, c'est tout
 
qu'est ce que tu as contre size_t ? ya aucun argument contre, dans tout les cas c'est ce qu'il y a de plus claire et de plus simple à utiliser, et de plus portable

Ben voyons, j'ai juste travaillé en Californie des années.
T'inquietes pas pour l'anglais, je n'ai surement rien a apprendre de toi sur le sujet.
Et en ce qui concerne le C non plus, apparement.
tu aurais regardé un peu partout a sizeof, par exemple en faisant "sizeof C language" avec google, tu aurais vu que les deux premieres entrées déja (j'ai pas ete voir plus loin) indiquent que sizeof retourne qque chose de type size_t.
 
A+,

C'est aussi ce que j'ai dit dans le post http://forum.hardware.fr/hardwaref [...] tm#t865312 (...si vraiment je veux être tranquille j'utilise un "unsigned long"...)
 

J'ai rien contre et je suis d'accord avec le fait que si toutes les tailles de tous les objets dans les fonctions diverses sont exprimées en "size_t", ce sera 100% portable que j'exprime mes tailles à moi aussi de la même façon.
 
J'ai juste dit dans le post http://forum.hardware.fr/hardwaref [...] tm#t869473 que je ne comprenais pas qu'un opérateur natif du C donne une valeur dans un type non-natif. Et j'ai dit aussi que dès demain je regarderai dans les docs. Tout l'inutile blabla qui en a suivi n'a été justement que du blabla...

 
entre utiliser unsigned long qui "pourrait" etre le type retour de sizeof et size_t qui l'est, tu choisi quoi ?
 
 

 
ben la voila l'explication justement, et size_t est l'alias du type natif retourné par sizeof

Pour moi, pour les projets que je développe, j'utilise "size_t" sans hésiter.
 
Pour un débutant auquel je veux montrer un algo, une manipulation simple, une particularité quelconque, alors je me concentre sur la particularité et j'essaye de rester à son niveau pour le reste. C'est pour cela que dans le code posté ici http://forum.hardware.fr/hardwaref [...] tm#t864455 je suis resté tout "int". On en revient au point de départ. Comme c'est dit dans ici http://forum.hardware.fr/hardwaref [...] tm#t865417, les règles doivent aussi prendre en compte le contexte pour lequel on écrit son code.

justement, tu ne peux pas savoir sur quelles architectures travaillent les gens, alors autant sécuriser la base. De même qu'un débutant peut concevoir que les float, c'est pour les flottant, les int pour les entiers, les char pour les caratères, il peut assimiler que size_t c'est pour les taille. Tu confonds algorithme et implémentation.
 
Je sais plus qui est qui : t'es pas entrain de retourner ta veste. Moi j'ai une logique simple : Ne fais pas faire à un débutant ce que tu ne ferais pas toi même.
 
cris56, gilou > vous avez vous aussi remarquez cette nouvelle vague dont lsdyoyo, Sve@r et lams ? ça nous promet encore de bon moments.

Je suis certain qu'un débutant connait int, char, float car c'est natif et il l'a sûrement appris de son prof. Mais je ne suis pas certain qu'il connaisse le type "size_t". En fait, je suis quasiment sûr qu'il ne le connait pas parce que ce n'est pas nécessaire à la compréhension immédiate du langage.
 

Moi j'ai remarqué que tu ne connaissais pas tes participes passés. De plus, de tous les forums où je suis, celui-ci est le plus désagréable dans son ambiance et tu y es très certainement pour quelque chose (ainsi que le modérateur qui modère pas grand chose). Dans les autres, les gens se parlent avec politesse et argumentent avec des "tu devrais... je pense qu'il vaudrait mieux... j'ai lu que... etc". Ici, il n'y a que des "c'est nul... c'est comme ça... il faut... il faut pas...". Mais t'inquiète pas, je ne vais plus y revenir bien souvent et probable que d'autres feront pareil. Quand cris56, gilou et toi resterez seuls, vous pourrez débattre du size_t jusqu'à la fin du C si cela vous chante.

ah bon parce que t'as argumenté toi ? à part sortir des liens foireux que tu n'as même pas lu et balancé tes vérités, t'es pas un modèle.
 
size_t est nécessaire à la compréhension immédiate du langage puisqu'il s'agit du type de retour de sizeof. Que ça te plaise ou non.

Sve@r > pourquoi différer l'apprentissage du type size_t ? ca ne peut etre que bénéfique

 
Ca veut pas dire qu'on doit pondre du mauvais code sous pretexte que c'est pour un debutant. Dans le Koenig & Moo, ma reference comme livre pedagogique pour apprendre le C++, size_t ainsi que string::size_type sont introduits exactement en meme temps que bool, unsigned, short et long. C'est a dire des le depart (int et string etant introduit au tout debut).
A+,

Koenig

Le Koenig & Moo, Accelerated C++, pour moi, c'est le bouquin modele pour apprendre ce langage.  
A+,

Certes, mais tu es sur le forum C là. D'autre part, je suis un peu du même avis que Sve@r : Pour des gars qui commencent probablement la programmation en passant pas le C (en fac, IUT, ou école d'ingé), début Octobre ne me semble pas forcément adapté à faire une surcharge de concepts, de types, etc. Donc, il ne me parrait pas indispensable de les abrutir avec size_t dès maintenant. Un peu plus tard, refaire une passe sur tout le langage, ça risque d'être plus approprié.  
 
D'autant que la plupart des profs n'ont pas appris comme ça, donc ils risquent de ne pas enseigner comme ça. A moins bien sûr que vous n'ayiez tous appris la programmation en un jour.  
 
De la même manière, certains d'entre nous on une autre priorité que le code parfait : mon employeur ne me paye pas pour faire du code lint-compliant, mais pour lui faire gagner de l'argent. Quitte à faire l'impasse sur certains détails de la norme qui ne sont pas forcément indispensables (je doute qu'il soit content si je lui dis que j'attend que Visual Studio supporte le mot-clé export pour finir de compiler mon projet), ou à faire des simplifications abusives (unsigned char=-128 est portable).  
 
Donc, si je décide que dans le cadre de mon projet, size_t peut être assimilable à unsigned long (si je décide de faire de la sérialisation par exemple), libre à moi. Ca me fera peut-être gagner du temps, de l'argent, et des stock-options. Ou peut-être pas : c'est à voir en fonction du contexte. Si je décide d'utiliser strstream par ce que un de mes compilos ne gère pas stringstream, ce n'est pas la peine de me sauter dessus à bras raccourcis parce que ce n'est plus standard : un peu de diplomatie ne fait pas de mal...
 
Certes, apprendre les concepts justes est important, mais il y a des limites. Un programmeur C++ qui ne sait pas faire les spécialisation partielles n'est pas forcément une sous-merde à mes yeux. Je ne sais pas pour vous...
 
 

 
Maintenant, j'ai vraiment un gros reproche à faire à certains d'entre vous (pas tout le monde, hein!): sans même connaître mon expérience (ou celle des autres), ou mes connaissances, je trouve que certains (surtout Taz) se permettent un peu trop d'attaques à 2 balles.  
 
Exemple, Taz : lorsque je dis que c'est un bug de compilo qui autorise à faire des unions avec des membres anonymes, tu pourrais soit acquieser, soit le réfuter de façon argumentée. Tu n'es pas obligé de venir déverser ton stress de nerd insatisfait sur moi: je ne suis pas ton psy.
 
Si tu me dis que la STL est écrite 100% en C++ standard et que le réfute, ce n'est pas la peine de me cracher ton fiel dessus, OK ? Parce que j'ai sans doute un peu plus d'expérience pratique que toi (à défaut d'avoir les connaissances théoriques), et que je sais le drame humain que représentent des allocateurs mal configurés...
 
Donc, essayez d'avoir un tout petit peu plus de retenue face aux nouveaux arrivants (on est pas tous des IUT en 1ère année), parce que le contexte actuel me donne pas vraiment envie de rester à trainer mes guêtres ici, et pourtant le niveau est quand même vachement élevé, et je suis sûr qu'il y a plein de trucs à apprendre...
 
Essayez aussi de répondre aux questions vraiment innocentes de certains (celle de Sve@r au sujet de size_t qui est définis dans un .h alors qu'il est censé faire partie du langage) avant de commencer les flames.
 
Voilà. This is the end of my rant. Désolé du HS.

A+,

Chez soi on fait ce qu'on veut tout le monde est d'accord.
Mais dans le cadre de cours, je ne saurais que trop conseiller de faire comme le prof. Ce conseil devient on ne peut plus vrai dans le monde de l'entreprise où les normes de codage sont ce qu'elles sont, bonnes ou mauvaises.

 
Tu devrais écrire un lintaz++. A ma connaissance, il n'y en a pas de libre sur le marché et ça t'éviterait d'avoir à gueuler, enfin, tu pourrais plutôt le faire de manière complètement automatique

Oula, dur à quoter.  
 
En fait, non, tu me prends pour plus extremiste que je ne suis. Je trouve perso que les cours de langages sont généralement mal fichus et pas assez "stricts": le prof t'explique que sizeof est une fonction, que size_t est un entier, etc. Et je trouve ça tout aussi dommageable que toi.
 
Mon intervention voulait dire: beaucoup de gens apprennent principalement auprès des profs, et essayons de ne pas trop leur semer de confusion, voilà tout. Donc, parler de size_t, de son utilisation dans les tailles mémoires, les chaînes et l'opérateur sizeof, c'est très très bien, et il faut le faire.  
 
Par contre, dire qu'un code est faux sans son utilisation, ça me parrait trop prématuré. Je trouve qu'il y a plein de trucs plus enrichissant (et moins "écoeurants) à apprendre dans un premier temps, comme l'encapsulation, les techniques algorithmique classiques, etc. etc.
 
Je pense qu'en fait ce qui nous "oppose" (c'est un bien grand mot), c'est l'ordre d'apprentissage des principaux thèmes du langage... Je suis plus pour une approche relâchée, qui se strictifie au fur et à mesure que l'on apprend (apparition systématique de la constness, suppression des "using" pour avoir conscience de ce qu'on utilise, tir à vue sur les "iostream.h", etc.)
 
Quand à l'aspect lint-compliant, bien sûr, tu es en droit de demander des revues de code, etc. Mais ça te coûtera plus cher. Ce prix est justifié pour du code embarqué, de la sécurité, de l'aérospatial, etc. Mais dans beaucoup d'autres domaines, il ne se justifie plus du tout. Là encore, tout est question de context: le monde n'est ni noir, ni blanc, il est Michael Jackson.  
 
Pour la remarque sur size_t et sur FILE: bah justement, tu viens d'y répondre, mais sans y metter une jolie forme fleurie et délicate. D'ou mon râlement de vieillard aigri  

Le truc c'est juste d'être amical avec ton prof. Vendredi encore, j'ai filé 2h de cours de C à un prof. Faut défendre ton steack. T'auras certainement quelqu'un devant toi quelqu'un plein de certitudes. Il t'enseigne le C, et si tu te pointes avec ton code, je sens déjà des réflexions 'j'ai de l'expérience, faut pas faire comme ça' ... 85% de chances qu'il n'ait jamais lu le K&R. Le tout c'est d'argumenter. Pas d'avaler des python.
 
J'ai des tas d'exemples vécus, des conneries monumentales ...
 
 
Et ça développe le sens critique  

Moi je vois pas en quoi écrire du code le plus standard possible coûterait plus cher.

Tu sais que c'est une super bonne question, et que la réponse est loin d'être évidente.
 
Lorsque je recrutais des gars pour faire du C++, j'utilisais le test Prometrics, et la proportion de gars ayant le niveau acceptable était de l'ordre du 98% percentile. C'est à dire deux gars sur 100 qui passent ce test. Et ces 2 gars là, ils coûtent forcément plus cher à trouver, à embaucher, et à maintenir à jour (training, etc.).  
 
C'est aussi con que ça !

Et ceci étant, ça ne paraît pas important de donner un meilleur niveau aux gens ?
 
 
edit : je suis pas vraiment d'accord avec toi. Une norme étant une coding-style universelle et qui devrait être implicite, le simple fait de la suivre permet d'augmenter la maintenabilité.

Je suis d'accord avec toi. L'actuelle génération de profs en programmation, c'est pas encore ça --- void main() et compagnie.
Argumenter, c'est un bon conseil mais faut voir également si le prof est souple et ouvert. Il existe des profs buttés malheureusement, je ne t'apprends rien. Si t'es un demi-dieu geek en prog, ca passera quand même, mais si t'es un élève moyen, il y a un risque de se faire sacquer pour pas grand chose quand même.
Il y a la théorie, mais dans la pratique faut parfois composer et même avaler des pythons

Les limites sont dans ta tête.

Pour moi, si. (sinon, je ne serais pas là).
 
Mais tu crois que c'est la priorité de toutes les boites qui externalisent en Inde ? Il ne faut pas s'étonner s'il y a beaucoup de programmeurs qui ne maîtrisent pas à fond leurs langages : de nos jours, la versatilité et la connaissance des APIs semble plus importante pour se trouver un boulot (et une fois que tu es dedans, c'est dur de se bouger le ciul et lire la norme en rentrant du boulot).  
 
A tort ou à raison...

Justement : comment tu peux être crédible si tu ne maîtrise pas la première des bibliothèque, la bibliothèque standard ?

 
Crédible auprès de qui ?  
 
Ton prof, il s'en tape, il fait des void main().
 
Ton recruteur, il s'en tape, il veut que tu connaisse C++, Java, .Net, Windows, Solaris, VMS.
 
Ton compilo, il s'en fout. S'il peut générer le code, il le fera.
 
Au final, à moins de vouloir devenir un puriste, c'est dur de se motiver pour se spécialiser. Et beaucoup ne veulent pas devenir puristes.  
 
C'est comme si je te disais : ne viens pas faire le cador sur ce forum tant que tu ne maîtrises pas tes accords et tes participes passés. Tu vois le parrallèle ?

même réflexion pour toi à propos du C.
 
Mais après tout, je peux faire comme toi :
voici le présent des verbes du premier groupe
 
je chantes
tu chantte
il chanteux
nous chantont
vous chanté
ils chante
 
tu vois le parallèle ?
 
si tu veux te la jouer correcteur orthographique, tu peux toi aussi revoir ta copie.

Ah non, faire comme moi, c'est ne pas sauter à la gorge du premier venu parce qu'il a fait une faute de grammaire, et lui mentionner poliment si tu penses que c'est nécessaire.  
 
C'est également avoir conscience que le 1er groupe est indispensable, mais que le subjonctif imparfait est juste utile si tu souhaites être complet et rigoureux.
 
Je ne joue pas les correcteurs orthographiques, parce que je n'ai pas écrit en français depuis un bon moment, donc j'ai du mal aussi. C'était juste un exemple de ton propre style...

En tout cas, ce que je tire de topic c'est que si j'ai un pb ou une question pointue, je suis content d'avoir des personnes compétentes sur hfr

 
Ouais, je suis dispo.