|
|
|
Radamanthe
Inscrit depuis le le 19/05/2009 à 12:57
Derniers messages de Radamanthe :
Ha ouais, ça c'est rock'n'roll, j'aime bien free. Avec des abonnés par papa noël qui se pendent et du sang partout. Bon ça !
Hoo pitié... un truc que j'aimerais bien que Numerama comprenne une bonne fois pour toutes, c'est qu'un technicien possède une arme de destruction massive pour convaincre : l'ignorance. Car l'excuse est non seulement facile, mais absurde. Il y a les API graphiques et les applications. Quand on fait un OS, même avec l'incompétence dont M$ peut faire preuve, on ne mélange pas tout et n'importe quoi ! S'ils veulent utiliser le moteur graphique de leur "machin explorer" pour afficher tous leurs bidules, rien ne les en empêche. C'est le navigateur en tant qu'application qui est en cause ici. Ca m'étonne pas du tout que M$ utilise ce genre de sophismes pour convaincre des juges (compétents pour interpréter des lois, mais à la rue pour comprendre comment un OS ou même un simple programme fonctionne), surtout quand l'OS n'est pas open-source, alors là bien-sûr, on peut dire absolument n'importe quoi et personne pourra vérifier. Mais je parie tout ce que vous voulez que si on force l'effacement de l'exécutable de leur bouzin explorer, l'interface du système ne part pas en sucette dès qu'on bouge une fenêtre... pourtant, si c'était le cas, plus rien ne devrait pouvoir s'afficher. Quant au fait que la place d'IE n'est plus la même qu'avant dans l'écosystème actuel, et qu'à ce titre, on ne pourrait pas les accuser de profiter d'une position dominante... super-bof, hein. D'abord, ils ont toujours une position dominante, ensuite, c'est un des stratagèmes qu'ils ont utilisé pour l'obtenir. Y'en a plus que marre de voir que les mêmes trucs fonctionnent toujours et encore, 30 ans plus tard, pour blouser la populace. Cessez de prendre leur déclarations pour des vérités, c'est exaspérant à la fin ! eduquons, le 21/10/2011 - 15:11 Cette dernière déclaration de Steve est ultra-connue et les idolâtres ne peuvent pas l'ignorer. Mais si une divinité à le droit de faire ce qu'elle veut, les mortels sont une autre histoire. Ceci dit, c'est drôle que je n'ai jamais pensé balancer ça à la figure d'un fan-boy occasionnellement. On devrait leur marteler ça sans cesse jusqu'à plus soif. Quand la connerie va trop loin, il faut pas hésiter à faire mal. pi3rr3-29, le 20/10/2011 - 19:03 T'inquiètes... Skynet sera bien assez malin pour trouver une solution plus efficace que celle-là pour éradiquer l'espèce humaine. En fait, le scénario de Terminator me semble plus réaliste, et on peut en imaginer pleins d'autres tout aussi dévastateurs.
Nul doute qu'en cas de défaillance quelconque, le programme devrait stopper le véhicule illico presto. Sinon, je trouve que Google joue un peu avec le feu. Il est évident qu'en cas de problème (même si je pense que c'est moins probable avec une machine respectant le code à la lettre qu'avec un humain), les responsables seront tout désignés, qu'il y ait un flou juridique ou pas. Centaurien, le 15/10/2011 - 16:53 Tes leçons d'optimisation ne m'impressionnent guère  Comme si copier était la seule opération qu'on puisse faire avec une chaîne... As-tu pensé aux nombreux cas, tout aussi fréquents, où l'on modifie une chaîne et où il faut recalculer la taille (correctement, sans bug) ? Et toutes les types de concaténations ? Les streams ? Et les chaînes croisées, les sous-chaînes (sans besoin de copier) ? D'autres leçons de bas-niveau à donner peut-être ?
Bah voyons... c'est vrai que les chaînes à l'époque n'étaient utilisées que pour afficher des lignes en mode texte... surement pas pour définir des sous répertoires (entre autres)... Je crois même qu'un imbécile d'informaticien, futur milliardaire, a même dit haut et fort qu'on aurait jamais besoin de plus de 640Ko de mémoire sur un ordinateur...
Oui, c'est ton avis, ça c'est sûr. Le mien, c'est que seuls les processeurs Intel (de la merde vite dépassée) avaient des instructions spécialisés pour les chaînes. Quelle idée saugrenue, mais bon, c'est vrai qu'avec des CISC, pourquoi se priver, hein... et puis les ordinateurs, ce n'était bon qu'à faire du traitement de texte après tout ! Pour moi, un langage bas-niveau doit rester minimaliste, comme un processeur. C'est pour ça qu'à ce niveau, une chaîne n'a pas plus de raison de contenir sa propre taille qu'un tableau, d'où C (et non pas Pascal ou Java). wykaaa, le 15/10/2011 - 14:43 Tu t'enfonces... je vois toujours pas ce que Harbison et Steele viennent foutre dans la définition de ce qu'est le C (pas plus que wikipedia). De plus, ils n'ont pas eu la bêtise d'écrire "The NULL character...", eux. Tu viens juste de les citer toi-même.
Le coeur de mon propos, ce n'est pas de savoir si TOI tu fais la confusion ou pas, mais que les débutants la fassent EUX en tombant par hasard sur tes crottes (aujourd'hui, demain, ou dans 20 ans) 
Pas qu'à l'origine ! C'est justement plus subtil que ça. La vraie question, ce n'est pas la valeur exacte de NULL, mais celle de zéro dans un contexte bien précis. Voilà ce que le K&R dit à ce sujet :
Relis bien la seconde et la dernière phrase. En d'autres termes et en français, zéro est le seul cas où, assigné ou comparé à un pointeur, lui donne une valeur spéciale (ie. invalide, que, bit à bit, cela donne l'adresse 0, ou -1, ou 2 valeurs, ou "42 rue de la connerie", ça n'y change rien, ça donne un pointeur invalide). C'était déjà défini comme cela dans la première édition du K&R. NULL n'est qu'une macro pour améliorer la lisibilité du code, car C est faiblement typé. Tu t'es joliment planté par la suite (et là, tu ne parlais pas de caractères mais bien de NULL) en prétendant que c'est C++ qui a mis les choses au point à ce niveau alors que c'est faux. Stroustrup n'a fait que suivre la définition de C sur ce point précis (il le dit lui-même vers le début de son pavé de 1000 pages, que c'est historique) avec une seule nuance : ne plus utiliser NULL, utiliser simplement 0. Plus besoin de NULL pour clarifier, puisque C++ est fortement typé. Pourtant, il existe encore des machines où 0 (bit à bit) est un pointeur valide. Stroustrup aurait-il fait la même erreur en pire ? Rooooh. Ritchie n'a pas rajouté simplement #define NULL 0 comme tu le prétends, il a d'abord dit que 0 dans le contexte d'assignation ou de comparaison avec un pointeur vaut pour un pointeur invalide. C'est ça, la nuance. NULL, ce n'est que du sucre, ça l'a toujours été, mais un sucre à n'utiliser que dans le contexte de l'assignation ou la comparaison avec un pointeur. Point Final. Ce n'est que quand des gus ont commencé à utiliser cela dans d'autres contextes (notamment des pointeurs arguments de fonction, même ANSI n'a pas résolu ce problème) que ça a commencé à sérieusement merder. Contrairement à ce que tu as dis, la définition de K&R marchait correctement, même sur des machines où la valeur bit à bit 0 pour un pointeur n'était pas un pointeur invalide (c'était au compilo de se démerder). Mouais, j'ai tout de même plus l'impression que le coup du "on le fait pas tout de suite par respect pour Steve" est une excuse facile pour ne pas dire "on a pris du retard, faut qu'on peaufine notre présentation"... mais bon, ne soyons pas mauvaise langue
Croux, le 14/10/2011 - 13:03 Ne fait pas l'imbécile. J'ai toujours très bien su à quoi wykaaa faisait référence, car j'ai justement les compétences pour repérer ce genre d'écart. S'il avait écrit "caractère null", ça ne m'aurait pas plus dérangé que cela (encore qu'on peut débattre aussi de la pertinence de représenter les chaînes de cette manière, il y a du pour, il y a du contre).
C'est bien ça le problème ! Autant les écarts dans l'usage des langages parlés, lus et écrits est tolérable, autant en ce qui concerne les langages informatiques, ça ne l'est pas. Et à fortiori C, plus que n'importe quel autre. Des erreurs anodines dans ce langage on déjà mis des vies en danger... par contre, corriger des idées reçues n'a jamais tué personne.
Mauvaise foi ou ignorance des conséquences ? 1. Prendre "parfois des raccourcis non rigoureux" est justement la source de bien des maux en C. 2. NULL est implicitement une macro puisque utiliser uniquement des majuscules pour un nom est à l'usage exclusif des macros (même si C permet de définir une variable de la sorte, c'est une très mauvaise pratique). 3. Ne pas indiquer cette règle implicite n'a pas de conséquence néfaste. Si NULL n'était pas une macro (un mot clé par exemple), ça aurait posé beaucoup moins de problèmes, même si cela violerait une règle implicite. Par contre, dans le contexte de C, indiquer qu'il s'agit d'un pointeur invalide et non pas d'un caractère est utile. Ne fait pas comme si on devait faire preuve du même formalisme que la norme dès qu'on parle de C : personne n'y comprendrait rien est on ne s'en sortirait bien évidement pas. Vulgariser ne signifie pas qu'on a le droit de manquer de rigueur. 4. Même ta référence à l'ASCII ne fait pas référence à NULL. On y voit "Nul", "null" ou encore "NUL". Ha si, tiens, dans les détails, en dessous, on y voit bien "NULL", et c'est une légèreté que je vais m'empresser de corriger (quand-bien même ASCII ne fait pas partie de la norme C, cette page de wikipedia fait tout de même référence au langage dans ce contexte). "NUL" me convient. Ca se joue à pas grand-chose, la rigueur, hein ? Tu dois sans doute me prendre pour un fanatique... t'inquiètes, j'ai eu moi aussi ma dose de tapage de doigt par les experts, il fût un temps, pour ce genre d'écarts (et même moins que ça). Note que je ne m'amuse pas à reprendre chaque erreur des participants à ce fil de discussion : la grande majorité n'y connait pas grand-chose et j'ai, sois en assuré, autre chose à foutre que de corriger la ramassis de bêtises qui ont pu être écrites depuis le début de cette news. C'est justement parce-que wykaaa semble avoir un niveau plus élevé que la moyenne (si toutefois on peut encore parler de moyenne) que je l'ai repris pour ce manque de rigueur : à ce titre, il est censé faire attention à ce qu'il écrit. Toi également. Pour ma part, je pense avoir fait ce qu'il fallait, en coupant les cheveux en quatre, comme tu dis. RIP, Ritchie. Croux, le 14/10/2011 - 01:46 Depuis 1989 (22 ans), en C, c'est la l'illustre norme qui fait foi, pas le K&R. On ne se base pas simplement sur le K&R pour faire un bon compilateur C, quoi que tu en dises. Cela nécessite un véritable travail de formalisme et seule la norme apporte cela. Le K&R est une vulgarisation de C, pas une formalisation (même s'il précède la norme de + de 10 ans). Et si la norme parle effectivement de "null character", ça n'a toujours rien à voir avec NULL qui n'est pas un caractère, ni pour la norme, ni pour le K&R par ailleurs. J'attend toujours tes références... voici la mienne (tirée de la norme) :
et "null" ici, se traduit par "invalide". Pas de "char" dans la phrase, ni dans le paragraphe, ce n'est même pas dans le chapitre. Et oui, C est vicieux à ce point. Comme tu le dis si bien, wikaaa a parlé de "caractère NULL" ce qui, sémantiquement parlant, est une hérésie qui tient en 2 mots. Maintenant, si tu penses que le fait de l'écrire en majuscules ou en minuscule ne change pas grand-chose, alors c'est que tu n'as pas fait suffisamment de C pour te rendre compte que ce genre de négligences a été la source de bien des confusions pendant bien trop longtemps. On ne compte plus les débats d'experts qui en ont plus que ras le bol de deboguer du code de merde à cause de ce genre d'anneries (et même celle-là en particulier). Alors maintenant, oui, on est pas sur un forum d'experts en C, loin de là. Mais c'est pas ça qui m'empêchera de corriger des idées reçues, même si cela a déjà été fait un million de fois, même s'il y en a encore qui font preuve de "jmenfoutisme" à l'égard d'un langage qui n'est clairement pas destiné au premier venu. Comme tu peux le constater, moi aussi j'en ai chié
Non, ça ne dépend pas d'un quelconque CPU (et merci, je faisait déjà du Z80 il y a 30 ans, c'est même avec ça que j'ai commencé à coder). Ca dépend du compilateur. Si le CPU n'est pas capable de faire ça en une instruction, quel que soit le langage, quel que soit le compilo, je l'ai déjà dit : même combat. C'est au compilateur (ou interpréteur) d'optimiser au mieux, le langage ne change rien à l'affaire. fbattail, le 14/10/2011 - 01:04 Tout à fait. Sinon, si vous cherchez des experts en C, c'est sur Usenet que vous serez le plus susceptible de les trouver : fr.comp.lang.c (français) comp.lang.c (anglais) (rajouter ++ à la fin pour c++). Le forum français est très peu actif de nos jours, est c'est bien dommage, car c'est là qu'ils se trouvent. Pour C++ par exemple, Bjarne Stroustrup, même s'il poste très rarement, fréquente assez régulièrement comp.lang.c++. zig, le 14/10/2011 - 00:21 Ce n'était qu'une impression. Il est tout à fait possible de produire du code C de qualité. Le vrai problème est que c'est difficile, même pour un gars qui a de la bouteille. Je le répète : ce langage nécessite des années d'expérience. Ce que tu ne peux pas dire, c'est que C est un mauvais langage à cause de ça. C est un excellent langage pour ce à quoi il est destiné : faire de la programmation système portable de bas-niveau. Encore faut-il respecter la norme à la lettre, et j'en conviens, ce n'est pas évident. La norme C99, c'est environ 1Mo de texte pur ! Et comme toute norme qui se respecte (ISO), c'est extrêmement formel et difficile à lire. Mais ça ne laisse, en théorie, aucune place au doute.
Bien au contraire, je trouve strcpy() très simple (par définition, le bas-niveau est simple, justement). Cette fonction fait exactement ce qu'elle dit. Et si tu lis correctement sa définition, tu es censé comprendre que c'est potentiellement explosif si le tampon de destination n'est pas assez grand : comportement indéfini. En anglais, "undefined behaviour" (UB). Et une UB, c'est par définition n'importe quoi. Le plus souvent quand on fait une erreur de ce genre, ça peut marcher pendant des années... jusqu'au jour où ça pète parce-que le contexte d'exécution est différent. La force de strcpy() est justement dans cette simplicité. Il n'existe aucune manière plus rapide de copier une chaîne en C que : while(*dst++ = *src++); En code machine, c'est on ne peut plus efficace. Et s'il s'avère que l'opération existe en cablé, alors strcpy() devient une simple macro pour faire appel au hardware. Je ne demande rien de plus, du moment que ça fait ce que ça dit sans chercher à faire plus pour rattraper les erreurs des pseudo-spécialistes.
Ce n'est pas nouveau qu'il existe tout un tas de "formateurs C" qui devrait plutôt apprendre aux gens à faire du tricot.
Pourquoi qualifier de spécialiste un type qui fait ça ? Pour moi, c'est un clown. Rien à battre de savoir qu'il a pondu un compilateur ou je ne sais quel bidule compliqué. Au passage, les compilateurs non-conformes sont légion en C, et ils ont eu peu de succès. Même les illustres GCC et autres Visual C++ ont encore des failles... extrêmement subtiles, certes, mais ils en ont encore. Il y a tellement de cas particuliers qui peuvent apparaître... mais toujours, c'est un problème de compilateur, pas de norme du langage. En tous cas, cette triste réalité n'est pas spécifique au C...
Le net est pollué à 99% de gens qui prétendent être des spécialistes de C. Je dis bien à 99%. Croux, le 14/10/2011 - 00:05 Rien à voir avec NULL. En C, NULL n'est pas un caractère. Et moi, je lis la norme, pas wikipedia ! wykaaa, le 13/10/2011 - 21:40 Ce n'est pas le langage qui fait les bugs, c'est le programmeur. La norme C n'est pas "boguée". Et d'ailleurs, le C original de D. Ritchie non plus. Il ne manquerait plus que ça, qu'on crée des langages bogués...
Ok, on va voir ça...
Encore du sophisme. NULL n'est pas un caractère. C'est un pointeur invalide. Quand on est expert en C, on fait très attention à la terminologie du langage quand on en parle. Et dans la norme C, NULL est un pointeur invalide. Il ne viendrait d'ailleurs pas à l'idée d'un véritable expert d'assigner NULL à un caractère (char). C'est une hérésie. En partant de ce postulat, c'est sûr que le premier guignol qui écrivait : void *c = 0; ...tombait dans un piège. Si aujourd'hui, en C99, c'est valide (car 0 dans le contexte d'un pointeur vaut NULL, ou du moins se "transforme" en NULL à la compilation), ça n'a pas toujours été le cas. Une chaîne C se termine par le caractère '\0' (anti-slash zéro).
Tu ne résumes rien. Les tableaux de C, tels que définis dans la norme C, n'ont rien à voir avec les tableaux des autres langages. C'est un concept bas-niveau, le même que celui des tableaux basiques en assembleur, à savoir une suite contigüe d'éléments en mémoire. Point. Dans la norme C, c'est certes un peu plus velu : il faut un minimum de formalisme. Mais fondamentalement, il n'y a rien de plus.
Faux. Dennis Ritchie n'a JAMAIS défini NULL comme valant zéro, mais comme un pointeur invalide. Il y avait des implémentations de C qui définissaient concrètement NULL avec autre chose que zéro (-1, 0xFFFF, ou une forme de 0x0000:0000, ou que sais-je encore), et c'était tout à fait conforme.
C'est le cas des x86 en mode paginé. D'ailleurs, une adresse dans ce mode n'est pas une valeur, mais une combinaison de 2 valeurs. Le mot "adresse" (address en anglais) n'a pas de sens en C. Dans la norme, il n'y a aucune définition de ce que tu appelles des adresses. La seule chose qui s'en approche, c'est le pointeur. Mais un pointeur est plus qu'une simple adresse.
Ce n'est pas une absurdité. De plus, on a pas attendu C++ pour lever cette définition (C90 ou C99, je ne sais plus). En fait, si D. Ritchie avait fait le postulat que NULL == 0, il n'aurait pas défini NULL : il aurait simplement utilisé 0. Et dans ce cas, presque personne n'aurait certainement jamais entendu parler de C, puisqu'il aurait été alors impossible d'implémenter C sur toutes les machines possibles et imaginables, et cela n'aurait été qu'un énorme flop. La force de Brian Kernighan et Dennis Ritchie (K&R pour les intimes), c'est justement qu'ils avaient une vision suffisamment abstraite de l'informatique pour créer un langage implémentable sur n'importe quel babasse, présente ou future, tout en restant suffisamment proche de la machine pour ne pas être dépassé par d'autres langages en termes de potentiel de performances.
Bien au contraire, l'apparition de C a résolu bien des problèmes. L'idée étant déjà de ne pas avoir à apprendre ouatmille assembleurs pour porter les programmes sur diverses machines. Enfin bon, t'inquiètes, c'est pas comme si tu étais le premier à dire n'importe quoi sur C. zig, le 13/10/2011 - 18:44 Le C est un macro-assembleur. Ce n'est ni plus ni moins qu'une abstraction de l'assembleur.
Sophismes. La vérité, c'est que C est tout sauf un langage pour débutants. Il demande des années d'expérience pour être maîtrisé. On apprend pas à faire du C correct en lisant des tutos, mais en lisant et en écrivant du code, beaucoup de code... jusqu'à ce qu'on arrive à comprendre ce qui est correct et ce qui ne l'est pas, et surtout, pourquoi !
Sauf que multiplier des pointeurs est illégal en C. Il faut "caster" pour multiplier des pointeurs, ce qui revient à faire du mauvais C (et puis quand on fait du C correct, on ne fait pas d'arithmétique sur les pointeurs plus complexe que l'addition ou l'indexation). Donc, ne pas s'étonner du résultat.
Ben voyons. C'est bien connu que les programmes C bloquent sans raison...
Ce n'est pas DU TOUT la faute au C.
Ca s'appelle de la programmation bas-niveau. Un peu comme jouer avec une bombe : la puissance est là, mais si tu fais n'importe quoi, ça te pète à la tronche. Rien de plus logique en somme.
Comme la grande majorité des microprocesseurs qui ont suivi. Après, si certains désirent créer des implémentations de la norme sur des CPU de merde, c'est leur droit. Du moment qu'ils respectent la norme (et la post-incrémentation en fait partie).
Même remarque. Et au passage, C ou autre chose : même combat. Je n'ai pas encore rencontré de langage et/ou de compilateur qui soit suffisamment "magique" pour améliorer l'architecture d'un microprocesseur ou rajouter des mnémoniques...
Sources ? (que je me marre un coup). Toutes les machines basées sur l'architecture Intel (ie. les x86, c'est le cas des PC) font de la post-incrémentation aussi facilement que de la pré-incrémentation depuis les tous premiers microprocesseur de cette famille. En l'occurrence, il s'agit d'un problème de compilateur, pas de langage. Bref... sinon, je serai gré aux apprentis programmeurs (rédacteurs ou commentateurs) de ne plus poster de soit-disant programmes C. C'est certainement le meilleur hommage que l'on puisse faire à D. Ritchie. RIP. NB. : Je serais également gré au rédacteur de l'article de rajouter "int " devant son "main". Merci. C'est pas la première fois que Google crée un langage : http://fr.m.wikipedi...ki/Go_(langage)
J'ai du pratiquer une bonne vingtaine de langages depuis 30 ans et franchement, je ne vois pas ce que celui-ci apportera de plus au moulin. M'est avis, après un premier coup d'oeil, que Google en a surtout gros sur la patate avec la situation catastrophique de Java, cette chose infâme adoptée par la majorité d'une industrie réputée élitiste qui se retrouve aujourd'hui bien emmerdée avec Oracle... Mouais, faut pas trop mordre la queue du diable non plus. C'est grosso merdo ce que fait ouvertement Google, ce n'est imposé à personne et chacun fait bien comme il veut. Pas de quoi en faire un fromage...
vf, le 10/10/2011 - 09:17 De toute évidence, je réfléchissais avec un cerveau majeur et vacciné que t'étais même pas encore dans les burnes de papa, alors tu vas calmer fissa ton enthousiasme, vu ? T'as pas affaire à tes copains d'école, là ! Ensuite, pour ton information, on a pas attendu d'inventer le fric pour inventer la culture. Si cette notion t'échappe, t'inquiète pas, ça viendra quand on t'aura inculqué suffisamment de connaissances sur l'histoire de l'humanité (voire même sa préhistoire). Sans blagues... je viens quand-même pas ici pour me faire insulter par des merdaillons boutonneux incapables d'aligner 3 mots sans faire de fautes  |
  1 offres à partir de 160 €
 21 offres à partir de 73 €
Télécharger
voissa anonymo,
ultrasurf,
redtube video downloader,
passion,
emule island,
adobe flash player,
restauration msn messenger,
emule,
Accès rapide :
Diagnostic |
eMule (et mods eMule) |
Photo numérique |
Outils Réseau |
Codecs et plugins |
Nettoyeurs |
Optimisation |
|
