Discussion :

[Jérôme_C]

même au gosse de 10 ans qui souhaite apprendre le C

On parle bien de la même chose ?

Tu donnerais la norme C pour un gamin souhaitant apprendre le C ???


Est-ce un hasard si la norme n'apparait pas dans http://c.developpez.com/livres/ ? Le premier livre qui est décrit est le fameux K&R, une "référence" ! Pourquoi le K&R est une référence et pas la norme ?

[baccali]

Tu donnerais la norme C pour un gamin souhaitant apprendre le C ???

Tout comme je lui donnerais un dictionnaire si il en avait besoin en plus de son livre de français! ( mais c'était juste une image, au passage! )

Ce que je veux dire c'est que si la norme était plus accessible, on s'y réfèrerait plutôt qu'à la petite étoile dans le manuel de son compilo.

[Jean-Marc.Bourguet]

Selon Mr Bourguet n'était ce pas l'utilisateur final qui a émit le besoin de ce standard?

Tu as les normes relatives aux equipements electriques que tu utilises?

avez-vous vu la liste et les postes de ceux qui ont fait ce standards? On ne trouve que du personnel de multinationnales ayant forcément leur intérêts dans cette histoire eux aussi.

Mieux que toi parce que j'ai vu ceux dont les societes sont petites ou qui participent a titre individuel.

Tout comme je lui donnerais un dictionnaire si il en avait besoin en plus de son livre de français! ( mais c'était juste une image, au passage!

Pour prendre ton imagine, donner la norme a un gamin de 10 ans, c'est comme lui donner le dictionnaire de l'Academie (et encore, le dictionnaire de l'Academie est plus lisible que la norme). Et un programmeur a besoin de la norme comme un journaliste du dictionnaire de l'Academie.

[Nathanael Marchand]

Ce que je veux dire c'est que si la norme était plus accessible, on s'y réfèrerait plutôt qu'à la petite étoile dans le manuel de son compilo.

A condition que le support soit de 100%
Y'a un bel exemple de norme c'est le SQL: si tu connais juste la norme, tu es "à poil" pour bosser, faut connaitre les specifications de ton moteur. Entre un T-SQL, un PL-SQL, etc c'est un peu la jungle. Rien que TIMESTAMP n'a pas la même definition partout.

[baccali]

Tu as les normes relatives aux equipements electriques que tu utilises?

Si tu veux faire des travaux chez toi vaut mieux respecter les normes non? Par exemple chez moi là je suis en train de rajouter de l'électricité dans une nouvelle pièce et je suis bien content de ne pas avoir à payer des centaines d'euros en plus des travaux simplement pour savoir comment je dois placer tel ou tel fil!

Mieux que toi parce que j'ai vu ceux dont les societes sont petites ou qui participent a titre individuel.

Tout comme chez la W3C ou autre il y'a aussi de petites entreprises ou "qui participent à titre individuel". Mais puisque je lis si mal, voici ma source, dispo sur Wikipedia : http://www.open-std.org/jtc1/sc22/wg...docs/n1558.pdf. Et force est de constater que des grosses entreprises, il y'en a pas mal!

A condition que le support soit de 100%

Justement, il n'existe (à ma connaissance du moins) aucune implémentation qui supporte à 100% la norme. Tout comme pour le SQL, c'est seulement si tu es attentif aux notes, lorsque les concepteurs ont eut l'immense bonté de le spécifier, dans le manuel de ton compilo qui stipulent que tel ou tel comportement du compilo ne suit pas la norme. Donc le seul moyens que tu as pour faire un code "portable" c'est de le tester toi-même dans toutes les situations. Ce qui fait qu'on se retrouve avec des logiciels qui ont leur propres routines d'allocation mémoire par exemple.

Alors que si la norme était accessible à tous, on pourrait implémenter son code en fonction de la norme et pas de son compilo. D'ailleurs, et c'est mon avis, les compilos respecteraient plus cette norme pour ne pas perdre des adeptes soucieux de faire du code portable. C'est pour cela que je disais que baisser le prix augmenterait considérablement la valeur de cette norme.

Pour prendre ton imagine, donner la norme a un gamin de 10 ans, c'est comme lui donner le dictionnaire de l'Academie (et encore, le dictionnaire de l'Academie est plus lisible que la norme). Et un programmeur a besoin de la norme comme un journaliste du dictionnaire de l'Academie.

On s'écarte du sujet. De l'académie ou de la NASA là n'est pas le problème! Le fait que le programmeur ait absolument besoin de la norme ou non là aussi n'est pas le problème. Le problème vient du fait que lorsqu'il en a besoin, il devrait pouvoir y avoir accès sans forcément avoir à débourser un budget aussi conséquent. Après ça reste mon point de vue. Et c'est ce qui sépare les adeptes du libre, open source etc.. des autres.

Pour moi le C est un langage dit "libre". Si quelqu'un devait toucher des sous dessus, c'est Denis Ritchie (du moins son héritier légitime) et Bell. Maintenant qu'une organisation se dévoue pour unifier les utilisateurs de ce langage, c'est tout à leur honneur. Qu'ils fassent payer l'utilisateur pour avoir accès à leur démarche l'est déjà beaucoup moins. Je me fiche de savoir si des entreprises déboursent des milles et des cents pour faire marcher leur organisations comme le W3C ou qu'ils utilisent le système des RFCs. Le problème vient du fait que ce n'est pas eux qui ont inventé ce langage ni même contribuer à son expansion. Donc s'attribuer des droits sur ce langage est en quelque sorte "malhonnête" selon moi.

Maintenant ils n'obligent personne à acheter une licence ou suivre leur norme pour utiliser le C. Comme Linus Torvald le dit si bien : "Les normes ce sont des papiers, et du papier j'en utilise tous les jours pour me torcher le c*l". Donc ils font ce qu'ils veulent et ils font marcher leur organisation comme ils peuvent. Je trouve juste incohérent de dire que leur système est mieux qu'un autre comme le W3C parce que moins commercial, dépourvu d'intérêt (ce qui est totalement faux) ou autre. C'est juste un système comme un autre. On trouve ça légitime ou non c'est un avis personnel. On y adhère ou non c'est un choix personnel.

[baccali]

Rien que TIMESTAMP n'a pas la même definition partout.

Et c'est bien là le problème! Pour continuer sur le parallèle avec le SQL, prenons le gars qui cherche à apprendre les BDD, lorsqu'il apprend avec PostgreSQL, il voit que le TIMESTAMP ne suit pas la norme. OK. Maintenant comment fait-il pour savoir quel comportement il doit normalement attendre du TIMESTAMP histoire de ne pas sécher lorsqu'il se retrouve dans un autre environnement en entreprise? (d'où mon analogie avec le gosse de 10 ans) Il débourse 300 euros? Certains trouvent ça normal apparemment, moi pas, mais comme j'ai dit c'est une question de point de vue!

[Nathanael Marchand]

Et c'est bien là le problème! Pour continuer sur le parallèle avec le SQL, prenons le gars qui cherche à apprendre les BDD, lorsqu'il apprend avec PostgreSQL, il voit que le TIMESTAMP ne suit pas la norme. OK. Maintenant comment fait-il pour savoir quel comportement il doit normalement attendre du TIMESTAMP histoire de ne pas sécher lorsqu'il se retrouve dans un autre environnement en entreprise? (d'où mon analogie avec le gosse de 10 ans) Il débourse 300 euros? Certains trouvent ça normal apparemment, moi pas, mais comme j'ai dit c'est une question de point de vue!

Ben même si il débourse 300€ pour la norme, il ne sera pas plus avancé puisque personne la suit de toute facon
C'est ce que je dis depuis le début, au lieu de mettre du pognon dans une norme théorique hors de prix, il suffit de lire l'implémentation de la norme par le moteur. MSDN et Oracle contiennent deux très bonnes bases de références gratuites et pas besoin de se payer la norme. La norme serait utile pour quelqu'un qui chercherait à créer un moteur de base de données et là, 300€ ca me parait une goutte d'eau.

[baccali]

il ne sera pas plus avancé puisque personne la suit de toute facon

Si on part comme çà pourquoi payer 300 euros pour la norme puisque je vais pas la suivre?! Autant bricoler un moteur à partir des sources d'information gratuites et accessibles. Donc pour conclure, les normes, ça sert à rien!

Nan là on tourne en rond mais plus sérieusement! Ce que je voulais dire c'est que si les normes étaient plus accessibles, l'utilisateur final s'orienterait vers l'implémentation la plus fidèle possible à la norme, ce qui pousserait les concepteurs à la respecter le plus fidèlement possible.

[Davidbrcz]

Ben même si il débourse 300€ pour la norme, il ne sera pas plus avancé puisque personne la suit de toute facon
C'est ce que je dis depuis le début, au lieu de mettre du pognon dans une norme théorique hors de prix, il suffit de lire l'implémentation de la norme par le moteur. MSDN et Oracle contiennent deux très bonnes bases de références gratuites et pas besoin de se payer la norme. La norme serait utile pour quelqu'un qui chercherait à créer un moteur de base de données et là, 300€ ca me parait une goutte d'eau.

Tout est dit !

En tant que programmeur "lambda", Il est à à mon sens plus essentiel de savoir comment se comporte son compilateur face à du code que de savoir ce que dit la norme. Je prends l'exemple du C++: certains codes compilent avec le compilo de microsoft mais pas avec g+. Qui a raison ? Qu'est ce qui importe ? Avoir du code qui marche le jour J avec mon compilo, ou écrire un code qui ne compile nul part mais qui respecte la norme? Par contre, une fois le "vrai problème" résolu, on peut poser la question sur internet pour savoir ce que devrait faire dans ce cas et faire remonter un bug ou what so ever.

Edit :

Pourquoi donc payer 300 euros pour la norme puisque je vais pas la suivre?! Autant bricoler un moteur à partir des sources gratuites. Donc pour conclure, les normes, ça sert à rien!

Nan là on tourne en rond mais plus sérieusement! Ce que je voulais dire c'est que si les normes étaient plus accessibles, l'utilisateur final s'orienterait vers l'implémentation la plus fidèle possible à la norme, ce qui pousserait les concepteurs à la respecter le plus fidèlement possible.

Pourquoi faire une norme ? Pour essayer que tout le monde la respecte au mieux, sinon ca serrait une jungle !!
Et les gens n'irait pas forcément vers le compilo qui respecte le mieux le norme. Il y a tellement de paramètre qui rentrent en jeu.

[baccali]

Tout est dit !

En tant que programmeur "lambda", Il est à à mon sens plus essentiel de savoir comment se comporte son compilateur face à du code que de savoir ce que dit la norme.

On est totalement d'accord.

Par contre, une fois le "vrai problème" résolu, on peut poser la question sur internet pour savoir ce que devrait faire dans ce cas et faire remonter un bug ou what so ever.

Si je veux distribuer les sources de mon logiciel, je dois obliger l'utilisateur à utiliser mon compilo. C'est ce que je trouve dommage! Alors que si la norme était respecté, je n'aurais qu'à suivre la norme et éviter les extensions de mon compilo. C'est l'intérêt et le but de la norme. Maintenant je ne nie pas que dans les faits cela se passe comme tu le décris et je le dis depuis le départ justement.

Pourquoi faire une norme ? Pour essayer que tout le monde la respecte au mieux, sinon ca serrait une jungle !!

Tu viens de démontrer par ton exemple que c'est déjà la jungle...!!

Et les gens n'irait pas forcément vers le compilo qui respecte le mieux le norme. Il y a tellement de paramètre qui rentrent en jeu.

Pour faire du code portable, si les gens ne devraient pas suivre la norme que devraient-ils suivre?

Vu qu'on est tous à peu près d'accord, ce sera tout pour moi, je m'arrête là sur le débat!

Cordialement

[souviron34]

Pour faire du code portable, si les gens ne devraient pas suivre la norme que devraient-ils suivre?

Le bon sens

Un bouquin de référence comme K&R suffit pour 99.9% du temps.

Utiliser les "features" des normes successives ne garantit en rien la portabilité (d'autant plus que certaines sont "caduques" assez vite : l'exemple des tmpname il y a mos d'une dizaine d'années est parlant).

Ce qui garantit la portabilité, c'est se baser sur les choses figurant dans les références "globales"..

Et, avec quelques petites astuces de réflexion, on peut quasiment tout faire de manière portable...

Mais il faut réfléchir un tantinet ..

[Bktero]

Merde, j'aurais jamais du parlé du fait que la norme est payante dans la première réponse de ce thread

Tout le monde a raison ici, vous n'arrivez juste pas à vous mettre d'accord. On a d'un côté les gens qui disent :

Il y a une norme. Si tout le monde la respectait et si tout le monde pouvait y accéder librement, ça serait génial.

Et de l'autre, ceux qui disent :

Il y a une norme. Le problème est que personne ne l'a respecte donc pas la peine de la lire, il suffit de lire la documentation de l'implémentation qu'on utilise.

Les premiers aspirent à un monde meilleur quand les seconds décrivent la réalité actuelle. Est-ce pour autant incompatible ? Non !


Et si au lieu de s'écharper sur "faut-il lire la norme ou pas?" et "faut-il la payer ou pas?", on parlait un peu de cette nouvelle norme C11 ?

[baccali]

Le bon sens

Un bouquin de référence comme K&R suffit pour 99.9% du temps.

Vas donc dire ça à ceux aux mainteneur de vim et leur fonction "faite maison" d'allocation de mémoire! Et pour les 0.1 % qui restent comment on fait?

Comment tu fais avec le bon sens pour implémenter une gestion correcte ET PORTABLE des signaux, de malloc ou de la taille des variables si tu n'es même pas au courant qu'elles sont dépendantes de ton environnement?

[souviron34]

Comment tu fais avec le bon sens pour implémenter une gestion correcte ET PORTABLE des signaux, de malloc ou de la taille des variables si tu n'es même pas au courant qu'elles sont dépendantes de ton environnement?

malloc ? problème ???


Désolé, en 25 ans de C sous plus de 6 OS différents et d'innombrables versions, jamais eu aucun problème avec malloc...

Taille des variables ???

Et.. Il y a des define comme INT_MAX, SHRT_MAX, etc etc, et les opérateurs sizeof() avec lesquels on peut programmer...


Le seul point est les signaux, pour la simple raison (et c'est à ma connaissance uniquement sous Windows) que M$ a toujours été "fière" de proclamer que eux ils fasaient des Message à des WindowHandle... mais qui est solutonné via cygwin.. (même problème avec les sockets)



Ce que je trouve quand même relativement symptômatique, c'est que ce soit des étudiants qui réclament et/ou prônent des normes ou montrent des problèmes de portabilité, alors que les devs d'expérience ici sont beaucoup moins tranchés..

Peut-être simplement parce que (signaux/sockets mis à part), les "problèmes de portabilité" sont en général légers à modifier si l'on a programmé assez correctement... et si on n'utilise pas 250 bibliothèques "tierces" comme c'est la mode...

[baccali]

Cher souviron34,

premièrement pas besoin de t'énerver. Si je t'énerve excuses moi.

Deuxièmement, INT_MAX et SHRT_MAX dépendent encore de l'implémentation donc je vois pas en quoi ça aide la portabilité que ces define soient dans ton système. D'ailleurs je ne vois même pas pourquoi tu en parles. INT_MAX, par exemple, est la valeur maximale tenant dans un int, pas une façon de forcer ton compilo à coder un int sur 4, 5 ou 6 bytes. Quel est le rapport? le standard n'en donne que les limites *at least*.

Troisièmement pour résoudre les problèmes de signaux il faut utiliser Cygwin. On parlait bien de problème de portabilité non?

Enfin je ne suis pas en croisade contre quoi que ce soit et je suis tranché sur rien du tout. On parle du standard C donc il fallait bien qu'à un moment on parle de portabilité.

Ce n'est pas parce que toi "devs d'expérience" tu n'as jamais eut de problème avec ces fonctions que tu peux parler pour tous les cas de figures possibles et imaginables. Je te prends un exemple de problème avec malloc qui pourrait poser problème. Sous BSD, lorsque tu fais un malloc de 0, le pointeur renvoyé peut-être NULL selon ton environnement, sous d'autres système tu reçois un pointeur valide (sous certains systèmes tu as même des malloc.conf donc...). Si toi tu as codé ton programme qui demande à l'utilisateur de rentrer la taille qu'il désire allouer en n'incluant pas cette possibilité dans ton code, tu t'exposes à des SEGFAULT. Sans parler des problèmes de threading qui n'ont été que récemment traités dans la norme C11.

Bref désolé de t'avoir dérangé grand "devs d'expérience". C'est tout pour moi pauvre étudiant n'y connaissant rien à la programmation.

[souviron34]

T'énerve pas, je ne visais pas que toi...

Je disais juste que (alors qu'on me l'a souvent reproché ici-même) , par exemple :

Je te prends un exemple de problème avec malloc qui pourrait poser problème. Sous BSD, lorsque tu fais un malloc de 0, le pointeur renvoyé peut-être NULL selon ton environnement. Si toi tu as codé ton programme qui demande à l'utilisateur de rentrer la taille qu'il désire allouer en n'incluant pas cette possibilité dans ton code, tu t'exposes à des SEGFAULT.

Ma politique a toujours été de faire :

Code :

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

1
2
3
4
5
6
7
8
if ( nb == 0 )
  ptr = calloc (1, sizeof(truc) );
else
 {
   temp = realloc ( ptr, (nb+1)*sizeof(truc) );
   if ( temp != NULL )
     ptr = temp ;
 }

et

Code :

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

1
2
if ( ptr != NULL )
  free (ptr);

Pour cette dernière epression je me suis déjà fait blaster sur ce forum, mais justement cela évite dans tous les cas les segfaults

C'est en cela que je disais : "coder intelligemment" (et ne pas se fier aux trucs qui disent "on peut faire free(NULL)... par exemple)

Ceci est totalement portable...

Deuxièmement, INT_MAX et SHRT_MAX dépendent encore de l'implémentation donc je vois pas en quoi ça aide la portabilité que ces define soient dans ton système. D'ailleurs je ne vois même pas pourquoi tu en parles. INT_MAX, par exemple, est la valeur maximale tenant dans un int, pas une façon de forcer ton compilo à coder un int sur 4, 5 ou 6 bytes. Quel est le rapport? le standard n'en donne que les limites *at least*.

Le fait que ce soit 4, 5, ou 6 dépend de l'architecture, non ? donc du matériel...

"forcer un compilo" à coder un int sur 4 ou 6 bytes n'est pas la bonne manière de faire...

"s'adapter" à la machine l'est...

Alors, en fonction du problème que l'on a , on peut utiliser différentes méthodes :

• stocker le nombre de bytes et s'en servir : nb = sizeof(int)
  
  
• utiliser différents types :
  

  Code :

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

  1
  2
  3
  4
  if ( INT_MAX == 32767 )
     ..
  else
  ...

• tester par rapport aux limites :
  

  Code :

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

  1
  2
  3
  4
  if ( valmax > INT_MAX )
     utiliser double
  else
     utiliser int

• ne pas s'en faire et utiliser le type qu'on souhaite
  
  
• toute autre stratégie..

Par définition il n'y a rien de portable à moins d'agir sur des bits... La taille des bytes, la taille des nombres, dépend de la machine et de son architecure..

Donc je ne vois pas où tu vois un problème particulier lié au langage...

Troisièmement pour résoudre les problèmes de signaux il faut utiliser Cygwin. On parlait bien de problème de portabilité non?

Je suis désolé, mais je n'ai encore trouvé personne pour faire fléchir Bill Gates et M$...

Bien que tout le monde soit d'accord pour dire que l'essence est mauvaise pour l'environnement, qui a les moyens de faire fléchir Shell ou Elf ou BP pour sortir autre chose ???

C'est bien joli d'oeuvrer pour la portabilité, mais quand un acteur majeur ne joue pas le jeu, ce n'est pas à la "norme" de s'adapter... Mais aux progammeurs d'attendre le bon vouloir de cet acteur, et en attendant de faire des #ifdef ...

Les fabricants de voitures continuent à fournir des voitures compatibles Diesel, SP95 ou 98...

HTML5 en est un autre exemple...

[baccali]

C'est en cela que je disais : "coder intelligemment" (et ne pas e fier aux trucs qui disent "on peut faire free(NULL)... par exemple)

Sauf que quand tu es un amateur qui n'a que le manuel de ton compilo tu es loin de te douter de certaines choses et ce qui est relatif à ton compilo passe la plupart du temps pour une valeur aussi sûre que ce qui est défini dans les standards.

Le fait que ce soit 4, 5, ou 6 dépend de l'architecture, non ? donc du matériel...

Non. C'est dépendant du compilo. Sous Cl (Visual C++), un long est de 32 bit que tu sois sur x64 ou x86. Si je le veux, aucun standard ne m'empêche de créer un compilo qui code des char sur 4 bits et pas sur 1 byte ni même des char de la taille des int.

Donc je ne vois pas où tu vois un problème particulier...

Perso, moi je ne me plains d'aucun problème en particulier. Je dis juste que déjà en temps normal le programmeur lambda n'a "aucun" moyen de savoir quels problèmes son code peut rencontrer. De là un standard n'est vraiment pas du luxe (même si ce n'est pas une solution miracle! La taille des int, par exemple, ne sera jamais standardisé puisque le C est utilisé pour produire du code machine sur des x86 comme sur des micro-controlleurs où un int sur 4 byte serait du gâchis). Et je trouve injuste qu'il faille payer 300 euros pour avoir accès à ces infos. Mais de toute façon, même en payant cette somme, il y'a de grande chances que tel compilo n'implémente pas tel comportement défini dans la norme, j'en suis conscient.

Je pense simplement que rendre la norme plus accessible obligerait de fait les implémentations à la respecter. D'où le débat avec Jean Marc Bourguet. Car l'utilisateur lambda se plaindrait de tel comportement de son compilo ne respectant pas la norme (norme qui a été créée sur sa demande, selon Mr Bourguet).

Si tu regardes, En parlant de HTML, je me souviens d'une époque où certains sites internet (dont le mien à l'époque) boycottaient Internet Explorer 6 avec un joli petit popup parce qu'il ne "respectait" pas suffisament les standards HTML (du moins certains tags avaient des comportements radicalement différents sous IE et sous firefox, le frames n'étaient pas du tout supportées ou très peu etc...). Et depuis, ils ont redoubler d'effort de ce côté.

[souviron34]

Sauf que quand tu es un amateur qui n'a que le manuel de ton compilo tu es loin de te douter de certaines choses et ce qui est relatif à ton compilo passe la plupart du temps pour une valeur aussi sûre que ce qui est défini dans les standards.

Parce que c'est le cas..

Sauf à aller dans des endroits qu'un "amateur" n'ira pas voir.. Et où un "pro" ira consulter la bonne doc... éventuellement lorsqu'il aura eu un warning ou error à la compil..

Non. C'est dépendant du compilo. Sous Cl (Visual C++), un long est de 32 bit que tu sois sur x64 ou x86. Si je le veux, aucun standard ne m'empêche de créer un compilo qui code des char sur 4 bits et pas sur 1 byte ni même des char de la taille des int.

Tu te contredis : en quoi le fait d'avoir une norme t'empêche de créer un compilo comme ça ???

Maintenant, de manière générale, de toutes façons je n'ai jamais utilisé de long, et en ce qui concerne les int, cela suit l'architecture...

ça m'étonnerait fort qu'un int sous x64 fasse 32 bits...

Donc en général on en revient au problème que je soulevais ci-dessus : ben oui, en info il faut savoir ce qu'on fait, et soit sur quelles machines on peut tourner, soit quelles sont les limites du problème qu'on traite..

La taille des int, par exemple, ne sera jamais standardisé puisque le C est utilisé pour produire du code machine sur des x86 comme sur des micro-controlleurs où un int sur 4 byte serait du gâchis).

Ton point de vue est extrêmement restrictif : C sert à faire du code de super-calculateurs comme des NEC jusqu'au micro, en passant par des PC , des workstations, et des calculcateurs moiris "imposants" mais pas "super", et ça n'est justement PAS un langage machine, mais un langage de haut niveau...

Ce n'est pas à cause de C que la taille des int ne sera jamais standardisée, mais à cause de la diversité des ordinateurs et des fabricants...

Des NEC sont déjà sur 128 bits, voire plus.. Des micros sont sur 8 bits, voire 4.. Dans les PCs, on a des 32 ou des 64.. Sans parler de certaines architectures exotiques (Harris et ses 36 bits par exemple, et je sais plus lequel avec 42)

Bref, de manière générale cela dépend du matériel et pas du langage...

Si tu regardes, En parlant de HTML, je me souviens d'une époque où certains sites internet (dont le mien à l'époque) boycottaient Internet Explorer 6 avec un joli petit popup parce qu'il ne "respectait" pas suffisament les standards HTML (du moins certains tags avaient des comportements radicalement différents sous IE et sous firefox, le frames n'étaient pas du tout supportées ou très peu etc...). Et depuis, ils ont redoubler d'effort de ce côté.

Et des utilisateurs lambda comme moi s'en sont amèrement plaints..

Car contrairement à ce que tu dis, c'était une exigence de (certains) programmeurs, et pas de l'utilisateur...

Et pour énormément d'utilisateurs, ils ont pesté contre ces p.tains d'informaticiens qui les obligeaient (encore une fois) à changer de version...

Et de plus cela allait à l'encontre de l'esprit même et de HTML et de l'informatique en général, qui est censée être compatible ascendante : toute nouvelle version est censée pouvoir faire marcher les anciennes... Simplement sans les nouvelles fonctionalités..

Je pense simplement que rendre la norme plus accessible obligerait de fait les implémentations à la respecter. D'où le débat avec Jean Marc Bourguet. Car l'utilisateur lambda se plaindrait de tel comportement de son compilo ne respectant pas la norme (norme qui a été créée sur sa demande, selon Mr Bourguet).

Cela a été le cas, avec le succès que l'on sait, pour toutes les versions des normes jusqu'à présent...

Ce que tu n'arrives pas à comprendre, c'est que pour faire bouger un fabriquant, il faut un certain poids.. Ce poids ne s'obtient pas via "des programmeurs lambdas", mais des cleints qui pèsent lourd sur soit les finances soit la réputation du fabricant..

Si un fabricant pour un marché de niche tel que par exemple tel ou tel micro n'a pas de plaintes de la part de ses clients parce que l'implantation telle qu'elle a été faite couvre les besoins, pourquoi voudrais-tu qu'il complexifie son compilo pour le rendre compatible avec quelque chose que ses clients n'utilisent pas ???

Modifier une norme d'un langage a pour origine en général la mise en évidence d'un manque cruel pour un grand nombre d'utilisateurs, OU une demande par un projet gigantesque : le calcul matriciel en Fortran a été souhaité par les concepteurs des logiciels de la station spatiale en 1980, et implantés en 1990, car la durée de vie prévue des programmes étaient d'au moins 40 ans...

Cependant, au nombre de millions de lignes de codes déjà programmées et actives dans un langage établi depuis longtemps, ces modifications sont en général des PLUS, pas des moins...

Tout programme se basant sur les versions antérieures est en général compatible (sauf quand on change les normes d'appel globales comme en C89).

Obliger la ré-écriture de tout ce qui existe pour convenir à la dernière norme est une absurdité que personne ne respectera jamais...

En conclusion, les compilos intègrent en général petit à petit les normes, lorsque d'une part les besoins s'en font sentir, et lorsque également les divers avis (de la communauté) trouvent que ces modifications apportent quelque chose... Il n'y a pas qu'une question de finances en jeu. Il y aussi les tests, et la compatibilité, et la vérification que tout ce qui compilait jusque-là continue à compiler...

Bref, c'est un problème techniquement complexe que chacun tente de résoudre comme il peut suivant sa boîte, ses clients, ses besoins, et certainement pas en se disant "c'est la nouvelle norme je dois être 100% conforme"..

C'est pourquoi cette partie du débat me semble stérile, voire puérile et/ou bisounours..

[baccali]

Parce que c'est le cas..

Sauf à aller dans des endroits qu'un "amateur" n'ira pas voir.. Et où un "pro" ira consulter la bonne doc... éventuellement lorsqu'il aura eu un warning ou error à la compil..

Parce que l'amateur n'aura pas ces erreurs à la compil? D'ailleurs depuis le départ on fait la distinction entre l'amateur et le "pro" et j'aimerai bien savoir pourquoi un amateur n'aurait pas le droit d'aller chercher des infos dans la norme ou ailleurs. Un amateur qui décide de coder un serveur web multi-arch et multi-système, c'est un amateur ou un pro?

Tu te contredis : en quoi le fait d'avoir une norme t'empêche de créer un compilo comme ça ???

Ou tu ne veux pas comprendre ce que je dis! Si un standard disait qu'un int est sur 4 bytes sur x86. Je plains la boite mail du mainteneur du compilo qui codera ses int sur 8.

Maintenant, de manière générale, de toutes façons je n'ai jamais utilisé de long, et en ce qui concerne les int, cela suit l'architecture...

Mais d'autres l'utilisent "dev d'expérience" .

Et je me répète mais les int ne dépendent pas de l'architecture, mais du compilo. Si les int sont sur 4 byte sur la plupart des systèmes x86 c'est pour des raisons pratiques. Pour rester sur le HTML, si je décide que l'affichage normal de mon navigateur est de taille 12 out of the box, ça ne dépend pas de l'architecture ou autre. Si on le fait tous, c'est parce que l'utilisateur final préfère çà comme çà.

Ce n'est pas à cause de C que la taille des int ne sera jamais standardisée, mais à cause de la diversité des ordinateurs et des fabricants...

Premièrement si C est un langage haut niveau, j'aimerai bien que tu me cite des langages que tu qualifies de bas niveau à part l'assembleur.
Deuxièmement C produit du langage machine et non du ByteCode par exemple. Voilà pourquoi la taille des int est importante dans ce langage. Rien ne m'empêche en C de créer un int sur 32 bits sur une arch x64. Le code sera plus lent etc... mais au final, qu'est ce qui m'empêche de le faire si j'en ai envie? Tu prends certaines choses pour acquises alors qu'elles sont loin de l'être si tu veux mon avis!

Car contrairement à ce que tu dis, c'était une exigence de (certains) programmeurs, et pas de l'utilisateur...
...

On ne va pas tourner autour du pot. Que ce soit les utilisateurs ou les programmeurs n'est pas le problème. Que ce soit les utilisateurs ou les programmeurs qui se sont plaints les premiers n'est pas important. Les utilisateurs, après avoir pestés, ont changé de navigateur. Donc pour garder leurs client, Microsoft a dû se mettre à jour.

Ce que je veux dire c'est qu'en C, le programmeur lambda a rarement les moyens de détecter tel ou tel comportement qui est spécifique à son compilo. Toi tu fais de la programmation défensive. C'est bien pour toi, mais comment as tu appris où mettre tes checks? Avec l'expérience et non avec un bouquin. Mais, le programmeur lambda, lui, doit attendre l'erreur. Hors pour cela une norme qui serait respectée par tous aiderait.

[Jérôme_C]

ça m'étonnerait fort qu'un int sous x64 fasse 32 bits...

Au moins là la réponse est simple
http://en.wikipedia.org/wiki/Integer..._integer_sizes

Je dis juste que déjà en temps normal le programmeur lambda n'a "aucun" moyen de savoir quels problèmes son code peut rencontrer.

Perso, mes problèmes de développeur sont plutôt des problèmes d'algorithmes, des erreurs dans le choix d'une condition, des problèmes de contenu d'une variable, des variables mal initialisée et assez rarement des problèmes où la définition même du langage C intervient.

Mais je ne suis peut-être pas un développeur normal.
...

Ou tu ne veux pas comprendre ce que je dis! Si un standard disait qu'un int est sur 4 bytes sur x86. Je plains la boite mail du mainteneur du compilo qui codera ses int sur 8.

Cf la réponse ci-dessus ou on ne sait même pas actuellement quel est le nombre d'octets utilisés pour l'encodage d'un int.

Pour reprendre une autre analogie, la norme en France est que la vitesse maximale sur une route ne peut excéder 130 km/h. En suivant la logique qu'on suit ici, toutes les voitures vendues en France ne pourrait rouler plus vite, ET tous les vendeurs ou fabricant sortant des voitures roulant plus se feront incendier par les clients qui sont au courant de la norme.

Tiens, c'est une idée, je vais transmettre mes PV à Renault, le fabricant va me les rembourser, j'en suis sûr.