Discussion :

[baccali]

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

On remarquera le "minimum requirement", le COMMON long integer size etc... merci!

ou encore :

A long integer can represent a whole integer number whose range is greater than or equal to that of a standard integer on the same machine

A long integer commonly requires double the storage capacity of a standard integer, although this is not always the case

Concernant les shorts :

In C, it is denoted by short. It is required to be at least 16 bits, and is often smaller than a standard integer, but this is not required

Et le meilleur pour la fin :

The sizes of short, int, and long in C/C++ are dependent upon the implementation of the language

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.

Ouai! C'est sûrement celui qui a ces problèmes qui doit pas être normal. D'ailleurs pourquoi se cassent-ils la tête à faire des normes qui ne me servent à rien!

[Jérôme_C]

Ouai! C'est sûrement celui qui a ces problèmes qui doit pas être normal. D'ailleurs pourquoi se cassent-ils la tête à faire des normes qui ne me servent à rien!

Je dis juste que ces problèmes dont la solution est le respect d'une norme, même s'ils existent, ils ne sont pas si courant par rapport à l'activité du développeur. S'il ne restait que ces problèmes de portabilité entre compilateurs dans les programmes en C, je serais bien content.

Ça sert, mais arrêtons de généraliser les quelques problèmes qu'on a rencontrés à ce propos (qui sur toute une carrière peuvent être nombreux) comme s'ils étaient les problèmes qu'absolument tous les développeurs débutants en C devraient connaitre.

[baccali]

Ça sert, mais arrêtons de généraliser les quelques problèmes qu'on a rencontrés à ce propos (qui sur toute une carrière peuvent être nombreux) comme s'ils étaient les problèmes qu'absolument tous les développeurs débutants en C devraient connaitre.

Faut pas non plus me prêter des propos simplement parce que vous avez envie de débattre. Je n'ai jamais dit que c'était des info cruciale, seulement que si on veut y avoir accès, on devrait pouvoir sans avoir à débourser 300 euros.

Mais à l'inverse ce n'est pas non plus parce que vous n'avez jamais rencontré ce genre de situations ou même qu'elles sont rares qu'il faut s'en foutre. Elles sont d'ailleurs beaucoup plus fréquentes que ce que vous avez l'air de penser à mon avis! Quand je vois le nombre de drivers, de micro-contrôlleur etc... programmés en C, ça fait peur! Et même pour du soft purement... soft, ce genre de problème peut subvenir (voir l'exemple de malloc cité plus haut)

D'ailleurs je ne sais même pas d'où vient cette histoire de débutant et de pros. Tous ceux que vous qualifiez de "pros" sont donc tous dans des entreprises qui se sont procuré la norme si je comprends bien?

[Bktero]

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

Ton discours sent un peu la résistance au changement et l'extrait cité ci-dessus cristallise pour moi cette sensation.

Certes, les utilisateurs n'étaient pas contents. Normal je devrais même dire. Mais que disaient-ils quand le même site ne s'affichait pas pareil avec deux navigateurs (IE et les autres pour simplifier ce que je lis) ? "Site de m*r*e!". Le programmeur a alors 3 solutions :

• coder en double
• coder un seul sans rien dire
• coder un seul en le disant

Aujourd'hui, tout le monde est content qu'IE affiche mieux qu'avant ? Si personne n'avait gueulé, rien ne ce serait passé.

Les utilisateurs ont souvent besoin d'être brusqués. Sinon, ils en seraient encore au minitel (ou encore avant...). L'informatique a besoin d'être brusqué sinon on en serait encore au boulier (ben, oui, ça calculait un boulier. Pourquoi avoir voulu faire une machine qui le fait tout seul ?). En fait, on a tous besoin d'être brusqués ! Ca ne se fait pas toujours en douceur, des fois on perd la compatibilité ascendante, des fois ça foire... Quand tu es passé des vinyles au CD, tu n'as pas dit "ben mince je peux plus lire mes vinyles sur la chaine CD?"

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 clients qui pèsent lourd sur soit les finances soit la réputation du fabricant..

Et ces clients qui pèsent lourds, pourquoi est-ce qu'un jour ils se décident à bouger ? D'un seul coup le grand chef décide qu'il faut que ça change ?

[souviron34]

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"

Euh... C'est toi-même qui l'a introduit :

post #62 ci-dessus :

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.

Ou tu ne veux pas comprendre ce que je dis! Si un standard disait qu'un int est sur 4 bytes sur x86.

Non je ne comprend pas..

Comme l'indique la page citée par Jerome.C, et conformément à ce que je disais, c'est très nettement lié à l'architecture du matériel...

Qu'on soit SQL, C++, C, Fortran, Pascal, Java, Python, VB, Delphi, ou 99% des langages, un int est défini par la taille de l'érchitecture, de même qu'un float ou un double..

Alors il y a certaines exceptions, plus d'ordre philosophiques (justement le int=32 en C sur 64, c'est pour dire que la base est 32 bits, et que long int n'a un sens qu'à partir du moment où on prend 2 int, comme sur une architecture 16), et pour des raisons de compatibilité avec les programmes existants (voir la note b-2 : "On 32-bit Unix, DOS, and Windows, int and long are 32-bits, while long long is 64-bits. This is also true for 64-bit processors running 32-bit programs" : ceci explique cela).

Mais, de manière globale, quel que soit le langage, c'est associé au matériel..

Aucun besoin donc de faire figurer ça dans une norme de langage, puisque 95% des langages font la même chose...

Un rappel :

Primitive data type

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 çà.

Voir ci-dessus... C'est FAUX en général...

Et ton analogie avec la taille de la police est totalement à côté de la plaque... La taille de la police n'influe pas sur la programmation HTML, mais sur la présentation...

En C tu as le printf pour ça...

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.

Mais bien sûr que si, C est un langage de haut niveau.. De même que C++, VB, Java, ADA, Pascal, Fortran, et autres....

Il n'y a qu'un (enfin des) langage(s) de bas niveau, et c'est effectivement l'assembleur...

Qu'est-ce qui peut te faire croire que C est un langage "bas niveau" ?? Le fait qu'il ne soit pas "objet" ????

Il te faut grandement réviser tes bases :

Voiri ici liens arbre des langages ! plus de 700 langages à découvrir

Deuxièmement C produit du langage machine et non du ByteCode par exemple.

Pratiquement en dehors de Java TOUS les langages produisent du langage machine : tous les langages compilés...

Séérieusement il te faut assimiler les bases

Tu prends certaines choses pour acquises alors qu'elles sont loin de l'être si tu veux mon avis!

Effectivement.. Voir plus haut....

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.

Mais comme le programmeur non-lambda...

C'est à ça que sert l'expérience... Que ce soit à petit ou haut niveau...

Pourquoi y-a-t-il le flag -Wall dans gcc ??? Justement pour avoir tous les warnings... Et tu remarqueras qu'ici tous les tutoriels recommandent de le mettre, et tous les progammeurs chevronnés le mettent aussi....

Pourquoi y-a-t-il le flag .IGNORE dans les makefile ? Parce que le comportement par défaut est que le makefile s'arrête dès qu'il trouve une erreur....

Quand ton programme crashe sur une machine alors qu'il marchait sur une autre, tu vas chercher pourquoi... Que tu sois novice ou expérimenté.. Et AUCUNE norme ne te mettra à l'abri de ça...

Franchement, je crois que tu places beaucoup trop "d'espoirs" dans une norme ou un document qui décrirait les comportements qui éviteraient d'avoir des erreurs...

Mais on en a toujours......

[souviron34]

Et ces clients qui pèsent lourds, pourquoi est-ce qu'un jour ils se décident à bouger ? D'un seul coup le grand chef décide qu'il faut que ça change ?

Non..

D'un seul coup ils veulent faire quelque chose, et le langage tel qu'il a été implanté montre une de ses limites, et la solution est dans l'implantation d'une autre partie de la norme...

Mais ils peuvent très bien ne jamais bouger.. (par exemple les VLA dans C99 n'ont pas fait bouger grand monde à ma connaissance...)...

[baccali]

OK alors par où commencer.

Tu aimes beaucoup jouer sur les mots alors je vais redévellopper certains points! ET CE SERA MON DERNIER MESSAGE.

Euh... C'est toi-même qui l'a introduit :

poste #62 ci-dessus :

Et pourquoi c'est devenu une règle que l'amateur (dans le sens de personne qui est en train d'apprendre le C dans mon message) ne rencontrerait pas ces problèmes? Je te pose encore une fois la question : Ces erreurs à la compil, il ne les aura pas lui?

Non je ne comprend pas..
...
Aucun besoin donc de faire figurer ça dans une norme de langage
...
Voir ci-dessus... C'est FAUX en général...

J'ai bien aimé le "en général"
Sinon tu n'as toujours pas compris! Si le COMMON est là c'est pas pour rien. Est ce que les int sont codés sur 32 bits pour des raisons matérielles, oui. Est ce que c'est obligatoire, NON. Tu n'es pas à l'abri d'un compilo qui code son long sur 32 bit comme cl donc si tu mises ta BDD sur des long tu as intérêt à te soucier de ce qu'il en est!

Donc tu as bien éviter la question en disant que TU n'utilises pas les long donc ON s'en fout, mais ceux qui l'utilisent, ils font comment? Ils s'en foutent aussi et distribue leur code en fonction de leur machine et le déclare "universel"?

Et ton analogie avec la taille de la police est totalement à côté de la plaque... La taille de la police n'influe pas sur la programmation HTML, mais sur la présentation...

En C tu as le printf pour ça...

Tour de claquette!!! Relis en lisant le fond de mon message et non la forme. D'ailleurs je ne vois pas trop ce que tu appelles "programmation HTML". Le HTML, c'est de la présentation pure non? Pour la programmation tu as le PHP, javascript et autre.

Ce que je dis c'est que ce n'est pas parce que tout le monde le fait que ce sera comme çà tout le temps. Si je veux mettre mon texte en 15 dans mon navigateur, qu'est ce qui m'en empêche. Même si je veux mettre une machine virtuelle sous mon compilo et traduire les codes C en ByteCode afin de gérer les int et les long, qu'est ce qui m'en empêche?

Qu'est-ce qui peut te faire croire que C est un langage "bas niveau" ?? Le fait qu'il ne soit pas "objet" ????

The terms high-level and low-level are inherently relative. Some decades ago, the C language, and similar languages, were most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level". Many programmers today might refer to C as low-level, as it lacks a large runtime-system (no garbage collection, etc.), basically supports only scalar operations, and provides direct memory addressing. It, therefore, readily blends with assembly language and the machine level of CPUs and microcontrollers.

Je rajouterai à çà le traitement des pointeurs qu'on ne rencontre pas ( ou n'est pas sensé rencontrer) dans les langages de plus haut niveau. Ce n'est pas pour rien que le C est le langage de prédilection pour la programmation système.

Il te faut grandement réviser tes bases :

Merci du conseil. Maintenant cite moi tous les langages (compilés ou non, où tu peux choisir l'emplacement en mémoire de ta variable, coder en mémoire la suite de bit 0100010 et faire des opérations binaires dessus (sans librairie), ou encore spécifier dans une structure que tu veux un vide de tant de bit entre telle et telle composant. Programmer un micro-controlleur etc... et là je te dirai que c'est un langage du même niveau que le C.

Je vais passer sur le reste pour simplement te répéter pour la ènième fois de ne pas te faire de film sur mes propos. Si tu relis mes messages tu verras que j'ai dit que les standards ne sont rien d'autres que des bouts de papiers.

Mais ce n'est pas parce que tu auras forcément des erreurs dans ton code qu'une norme ne te permettrait pas d'en anticiper certaines et de ne pas avoir à débugger ton code pendant 10 ans parce que ça marche sur une machine et non sur l'autre. Au moins de ne "rien avoir à reprocher" à ton code si il marche sur ton compilo et non sur un autre parce que ton code sera conforme à la norme. Et si tous suivaient la norme, les scripts configure serait beaucoup plus simple on aurait beaucoup moins à se casser la têtes dans tous ces #define (Et encore faut-il savoir où les placer)

Donc lorsque tu bosses pour une entreprise privé qui ne bosse que dans son environnement et n'a pas de souçi de portabilité (et je suis sûr que c'est ton cas), tu ne rencontreras sûrement jamais ce genre de problème. Mais Le -Wall de gcc ne te préviendra pas d'un intervalle dans un case ou d'une packed structure qui n'est pas portable. Le Makefile encore moins donc tu as intérêt à ne pas baser ton code là dessus lorsque tu es sur un projet comme postgreSQL!

Pour conclure, je reverrai mes bases, merci. Mais sérieux, tu viens de me prouver avec brio que l'expérience ne fait pas forcément de toi un "guru" de la programmation (ni même un programmeur avertit aparament!).

[Jean-Marc.Bourguet]

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!

Le respect de celle-ci est une obligation légale. Son prix est de 321 € HT, 130 € de plus que celle de C (dont le respect n'est en rien une obligation légale). Tu peux la consulter dans les délagations locales de l'AFNOR.

Mais puisque je lis si mal, voici ma source, dispo sur Wikipedia : http://www.open-std.org/jtc1/sc22/wg...docs/n1558.pdf.

Là tu n'as que ceux qui ont participé à cette réunion. Ce choix est en effet biaisé en faveur de eux ayant un bon support de leur entreprise et donc des employés de grosses entreprises ou y ayant un intérêt important.

Alors que si la norme était accessible à tous, on pourrait implémenter son code en fonction de la norme et pas de son compilo.

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.

Quel est la différence pratique entre la norme publiée et les derniers drafts disponibles (et pouquoi penses-tu que des liens vers ces derniers brouillons disponibles restent disponibles aussi longtemps?)

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

Pour faire du code portable, respecter la norme est un moyen. Il n'est pas absolu (parfois il vaut mieux s'en écarter), il n'est pas suffisant (en pratique il faut s'imposer des contraintes en plus).

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 peux même faire des choses stupides tout en respectant la norme. Et ne pas la respecter est parfois sensé (j'ai utilisé un compilateur qui avait ses chars sur 7 bits et les chars ne couvraient pas toute la mémoire, il y avait un bit sur 36 qui n'était pas couvert; il était plus utile dans ce mode que dans le mode conforme à la norme avec des chars sur 9 bits).

De là un standard n'est vraiment pas du luxe

Un bon manuel de référence est plus utile que la norme au programmeur lambda.

[Jérôme_C]

Le respect de celle-ci est une obligation légale. Son prix est de 321 € HT, 130 € de plus que celle de C (dont le respect n'est en rien une obligation légale). Tu peux la consulter dans les délagations locales de l'AFNOR.

Et encore, je n'ai pas connaissance que l'assurance va te faire confiance si en tant qu'amateur ou professionnel non reconnu par une assurance professionnel tu va être couvert si tu suis cette NF C15-100. Même si tu suis la norme, il faut le prouver, et la manière la plus simple reste de faire appel à un expert qui va reconnaitre que tu as travaillé selon la norme. Sinon, en cas de sinistre, même si ça n'a rien à voir, l'assurance va pointer du doigt une modification de l'installation électrique d'origine...

L'expert aura intérêt à acheter la norme de l'AFNOR.

Le particulier n'a aucune intérêt à l'acheter mais peut simplement télécharger les recommandations publiées gratuitement par l'AFNOR...

Pour cette norme du C11, je ne sais pas exactement quel est le public de cette norme, mais je crois bien qu'il doit être loin de ce que certains associent aux simple usagers du langage C, et nombre de professionnel (personnes payés pour développer) n'ont pas accès à cette norme sans s'en porter plus mal ni s'en coder à en faire peur de grand puriste de la norme.

[baccali]

Bonjour

Le respect de celle-ci est une obligation légale. Son prix est de 321 € HT, 130 € de plus que celle de C (dont le respect n'est en rien une obligation légale). Tu peux la consulter dans les délagations locales de l'AFNOR.

Nan mais Jerome C, tu t'enflammes! (*touche d'humour, à prendre au second degré*) Jean-Marc Bourguet a bien préciser qu'elle est consultable sur le site de l'AFNOR. C'est la loi et c'est la logique que je soutiens. Ce genre d'info ne devrait pas être payante, sauf pour un auto-financement au même titre que les dons que l'on fait à Wikipédia par exemple. (Attention, je ne dis pas que si Wikipédia faisait payer ses services, ce serait aussi illogique que pour la norme, bien au contraire) C'est comme si on devait payer une licence pour tondre son jardin (bon comparaison pourrie mais c'est en somme l'idée). L'alinéa 3 du décrêt du 16 juin 2009 (je dormirai moins bête ) dit bien que si une norme est payante et obligatoire elle doit pouvoir être consultable librement sur leur site. l'AFNOR y est obligée.

C'est le même principe pour moi en C même si on ne parle plus de sécurité etc... Le fait est qu'il s'agit d'un domaine d'ordre public ( selon Denis Ritchie et Bell). Donc qu'un partie "lambda" fasse payer des droits sur un tel sujet c'est comme, encore une image à prendre au second degré, désolé, mais elle exprime assez bien ce que je pense et surtout je ne vois plus d'autre façon de l'exprimer après 2 jours de débat! :

Imaginons qu'aujourd'hui je (l'ISO) change (la norme) les pompes à essences (le C) de façon à ce que l'on perde 10% lorsque l'on remplit notre réservoir. Toutes les stations services (les systèmes et compilos) me suivent et changes leurs pompes. Si je (moi qui ait changé les pompes) sais comment faire pour ne pas perdre ces 10% (la norme) ai-je le droit de faire payer l'info à un prix exhorbitant? Pourtant, les gens continueront à utiliser les stations services, et des gens qui auront vu de loin quelqu'un qui m'a acheter l'info peut toujours essayer de reproduire le geste(drafts) mais est-ce que parce que les riches ne se plaignent pas les pauvres n'ont pas le droit de réclamer ces 10%.
(encore désolé pour la comparaison pourrie! même si elle exprime assez bien mon point de vue je trouve)

Là tu n'as que ceux qui ont participé à cette réunion. Ce choix est en effet biaisé en faveur de eux ayant un bon support de leur entreprise et donc des employés de grosses entreprises ou y ayant un intérêt important.

Effectivement. Mais le fait est que cette équipe reflète à mes yeux le même système que chez n'importe quel autre organisme comme le W3C où là aussi il doit y avoir des petites, moyennes et grosses entreprises.

Tu peux même faire des choses stupides tout en respectant la norme. Et ne pas la respecter est parfois sensé (j'ai utilisé un compilateur qui avait ses chars sur 7 bits et les chars ne couvraient pas toute la mémoire, il y avait un bit sur 36 qui n'était pas couvert; il était plus utile dans ce mode que dans le mode conforme à la norme avec des chars sur 9 bits).

On est d'accord seulement on est là dans un cas particulier qui ne s'applique qu'à votre environnement. Je n'ai jamais dit qu'il fallait respecter la norme peu importe la situation. Je le répète encore, la norme, ce n'est qu'un bout de papier! Mais lorsqu'on a un soucis de portabilité, la norme n'est pas un moyen absolu, mais c'est plus que très souvent une valeur sûre. Si je veux un code portable sans pour autant compiler mes modules en statique, vaut mieux me baser sur la libc que je sais que j'ai 99,9% de chance de retrouver peu importe le système plutôt que la lib gstring ou autre. C'est le standard. Il n'est pas absolu et ne garantit pas la portabilité, mais c'est un moyen non négligeable et dans 90% des cas vaut mieux miser dessus.

Un bon manuel de référence est plus utile que la norme au programmeur lambda.

Oui mais lorsque le manuel n'est plus suffisant. Comment fait-il? D'ailleurs encore faut-il le trouver le bon manuel! La norme est peut-être un vrai casse-tête à décoder, mais après l'avoir comprise, on se rappelle, se rend compte ou décèle en codant tel ou tel comportement "spécial".

Quel est la différence pratique entre la norme publiée et les derniers drafts disponibles (et pouquoi penses-tu que des liens vers ces derniers brouillons disponibles restent disponibles aussi longtemps?)

Si on considère les drafts et la norme elle-même comme la même chose, là mon avis est différent! Mon idée n'est pas que l'information est inaccessible (on trouve de tout sur internet de toute façon et je sais bien que c'est l'ISO même qui publie les drafts). Mon propos est que le principe de faire payer cette information à l'utilisateur final est "incohérent".

Maintenant concernant les drafts elles-même, eh bien... Disons que ce n'est pas parce que j'ai la béta de Windows 8 que j'ai Windows 8 et que ça va m'empêcher de payer la version finale. Les drafts restent aussi longtemps justement parce qu'on se débrouille comme on peut avec ce qu'on a vu que la version finale est à ce prix!

Après, qui en a besoin et qui n'en a pas besoin, là n'est pas le problème. Lorsque l'on fait des études, on peut s'arrêter après un BTS ou continuer en école d'ingé. Un simple manuel est suffisant au débutant, certe, mais lorsque l'on veut aller plus loin et se lancer dans un projet comme l'écriture de linux par exemple (débutant ou non), avoir la norme évite parfois de voir ses commits rejetté sans comprendre pourquoi!

[souviron34]

Et pourquoi c'est devenu une règle que l'amateur (dans le sens de personne qui est en train d'apprendre le C dans mon message) ne rencontrerait pas ces problèmes? Je te pose encore une fois la question : Ces erreurs à la compil, il ne les aura pas lui?

Je ne sais pas ce que tu as avec ça : je te dis que tout le monde peut avoir des problèmes et les voit la plupart du tempsà la compil...

Sinon tu n'as toujours pas compris! Si le COMMON est là c'est pas pour rien. Est ce que les int sont codés sur 32 bits pour des raisons matérielles, oui. Est ce que c'est obligatoire, NON. Tu n'es pas à l'abri d'un compilo qui code son long sur 32 bit comme cl donc si tu mises ta BDD sur des long tu as intérêt à te soucier de ce qu'il en est!

Tu n'es pas non plus à l'abri d'un fabricant de voitures qui fabrique des voitures à 3 roues...

Est-ce pour autant qu'il doit exister une norme que tout le monde devrait rspecter pour dire qu'une voiture doit avoir 4 roues ????

Tour de claquette!!! Relis en lisant le fond de mon message et non la forme. D'ailleurs je ne vois pas trop ce que tu appelles "programmation HTML". Le HTML, c'est de la présentation pure non? Pour la programmation tu as le PHP, javascript et autre.

Non, la programmation HTML c'est les balises.... (tu peux faire une page HTML avec un éditeur de texte tout simple)

Avec quelle police c'est affiché on s'en fiche, et la norme HTML s'en fiche...

Je rajouterai à çà le traitement des pointeurs qu'on ne rencontre pas ( ou n'est pas sensé rencontrer) dans les langages de plus haut niveau. Ce n'est pas pour rien que le C est le langage de prédilection pour la programmation système.

Les pointeurs en C++

Using pointers in Java

Pointers Fortran 90

Quant à la citation de Wiki, c'est sûr que si l'on considère que un Garbage Collector ou un langage objet est nécessaire, alors Fortran, Pascal, ADA, et une multitude d'autres langages sont également "bas-niveau"...

ça me fait doucement rigoler : bas niveau, de mon point de vue, c'est quand on ne programme qu'en fonction de la machine, dans un langage directement compris par la machine..

Quand je vois des instructions comme fopen, readdir, strstr, while, atan2, etc etc, je ne vois pas de langage machine, mais un langage orienté utilisateur, et donc un langage de haut niveau..

Enfin visiblement tu es représentatif d'une génération...

Mais quand je rapproche cette discussion de celle sur la librairie standard, je maintiens que je pense qu'il te manque un point de vue plus général....

[Niark13]

AMHA, ce n'est pas un problème de conflit de générations (genre les "vieux" qui coderaient en C vs. les jeunots et "leurs langages de haut niveau modernes"). Après tout, Lisp est plus vieux que le C de 15 ans, n'est pas non plus orienté objet et il est de plus haut niveau, ne serait-ce que par son typage dynamique, sa gestion automatique de la mémoire et sa capacité à capacité à manipuler le code source en tant que structure de données.
Personnellement, je n'aurais pas mis non plus le C dans la catégorie des langages de haut niveau, précisément parce que les tailles de ses types sont dépendants de l'architecture de la machine et que la manipulation des pointeurs est omniprésente.

Bref, si on recentrait le débat sur les ajouts de cette nouvelle norme ? Par exemple le bloc _Generic, dont j'ai vraiment du mal à voir l'intérêt, si ce n'est pour réécrire tgmath.h...

[baccali]

la manipulation des pointeurs est omniprésente.

Pour qu'il comprenne encore faudrait-il que toute son expérience lui apprenne à différencier les pointeurs des références et que le C++, c'est du C avec des extensions! (désolé pour les puristes) parce que ça m'a l'air encore un peu flou dans ses bases si solides! Ou alors faudrait que j'aille faire un tour sur un site web bien "programmé"!

Par exemple le bloc _Generic, dont j'ai vraiment du mal à voir l'intérêt, si ce n'est pour réécrire tgmath.h...

Apparement ce serait pour de imiter l'overloading des fontions en C++. Je n'aime pas trop ça mais ça peut avoir son utilité

[Obsidian]

le C++, c'est du C avec des extensions!

Ça, ce n'est pas vrai.

Certes le C++ a été construit autour du C et en réintègre la majeure partie mais, pour le reste, passer du C au C++, c'est comme passer de la 2D à la 3D, ou du dessin à la sculpture. Pour en tirer pleinement parti, ça implique de réfléchir complètement différemment et, donc, de reprendre la conception et l'architecture d'un soft depuis zéro. Le C++ est bien plus que le « C with classes » initial.

Certes, un code C portable et « canonique » vis-à-vis de la norme aura de grandes chances d'être compilé sans problème par un compilateur C++. Ça n'en fait pas pour autant un programme en C++.

[baccali]

Ça, ce n'est pas vrai.

Certes le C++ a été construit autour du C et en réintègre la majeure partie mais, pour le reste, passer du C au C++, c'est comme passer de la 2D à la 3D, ou du dessin à la sculpture. Pour en tirer pleinement parti, ça implique de réfléchir complètement différemment et, donc, de reprendre la conception et l'architecture d'un soft depuis zéro. Le C++ est bien plus que le « C with classes » initial.

Certes, un code C portable et « canonique » vis-à-vis de la norme aura de grandes chances d'être compilé sans problème par un compilateur C++. Ça n'en fait pas pour autant un programme en C++.

Ah ah je savais que ça allait faire jazzer! Oui on est d'accord j'aurais dû dire ça comme çà (je suis vraiment pas ou très peu du C++ donc je ne connais pas encore tout ce qu'il apporte en plus du C. Par contre tes analogies laissant sous entendre que le C++ est mieux que le C me picotent un peu! C'est plutôt une façon différente de concevoir son soft. POINT. Car je n'ai pas encore vu d'atout du C++ qui ne soit pas qu'une "aide" (le mot est mal choisi!) apportée au programmeur C++ comparé au C (implémentable dans une lib par exemple) mis à part la façon de compiler. Mais çà c'est un autre débat et j'ai eut ma dose sur les google groups

[Jean-Marc.Bourguet]

Certes, un code C portable et « canonique » vis-à-vis de la norme aura de grandes chances d'être compilé sans problème par un compilateur C++.

Il y a peu de chance. Du code canonique en C ne va pas caster le resultat de malloc ce qui ne va pas passer en C++. (Les autres differences sont plus annecdotiques, encore que l'usage de const est generalement plus suivi en C++ qu'en C).

[souviron34]

Après tout, Lisp est plus vieux que le C de 15 ans, n'est pas non plus orienté objet et il est de plus haut niveau, ne serait-ce que par son typage dynamique, sa gestion automatique de la mémoire et sa capacité à capacité à manipuler le code source en tant que structure de données.

Nous sommes d'accord..

Personnellement, je n'aurais pas mis non plus le C dans la catégorie des langages de haut niveau, précisément parce que les tailles de ses types sont dépendants de l'architecture de la machine et que la manipulation des pointeurs est omniprésente.

Non, elle n'est pas plus "omniprésente" que en Fortran, en Pascal, etc..

En fait, la seule vraie particularité de l'utilisation des pointeurs en C, outre le type "void *", est l'utilisation que l'on peut en faire pour faire des fonctions récursives et donc parcourir/décrire des arbres.

Il se trouve que c'est particulièrement enseigné comme spécificité, mais l'écriture (en Fortran 77 !!!) :

http://www.fortran.com/F77_std/rjcnf0001-sh-8.html

Code :

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

1
2
CHARACTER A*4, B*4, C(2)*3 
EQUIVALENCE (A,C(1)), (B,C(2))

est bien une utilisation de type "pointeur".. (le B et le C pouvant d'ailleurs être des tableaux de INTEGER, de REAL, de DOUBLE PRECISION, etc..)

Que énormément de programmes Fortran utilisent, le pourcentage étant d'environ 95% des programmes d'avant 1990.... (et c"était valable depuis 1966 et le Fortran 66)



Maintenant, en ce qui concerne la taille des types, c'est vrai de Fortran, de Pascal, de Java, de C++, et de au moins la moitié des langages de l'arbre cité (en fait de 99% voire 100% des langages compilés)

Alors peut-être que dorénavant vous appelez "bas niveau" tous ces langages, mais ce n'est pas l'acceptation que j'en ai... et que j'ai vu utiliser dans les bouquins et les formations et le milieu...

J'avoue être plus que perplexe face à de telles affirmations...

[souviron34]

Il y a peu de chance. Du code canonique en C ne va pas caster le resultat de malloc ce qui ne va pas passer en C++. (Les autres differences sont plus annecdotiques, encore que l'usage de const est generalement plus suivi en C++ qu'en C).

au contraire du code canonique en C va caster le résultat de malloc (si l'on suit K&R et non la norme), puisqu'à l'époque le cast était obligatoire..

En fait, tout dépend de ce qu'on appelle "canonique"

[Obsidian]

Ah ah je savais que ça allait faire jazzer! Oui on est d'accord j'aurais dû dire ça comme çà (je suis vraiment pas ou très peu du C++ donc je ne connais pas encore tout ce qu'il apporte en plus du C.

Il faut le considérer comme un autre langage. Il y a eu un grand débat, notamment ici, entre ceux qui pensent qu'il vaut mieux cerner le C en entier puis embrayer vers le C++, et ceux qui pensent qu'il faut directement commencer par le C++, qu'il faut « penser C++ » comme dirait Bruce Eckel, et ne pas s'encombrer du passé. Je trouve que les deux approches se défendent.

Par contre tes analogies laissant sous entendre que le C++ est mieux que le C me picotent un peu!

Ce n'est pas ce que j'ai sous-entendu. Loin de là. Si c'était le cas, il n'y aurait plus de forum C du tout, et tu peux constater qu'il se porte plutôt bien.

C'est plutôt une façon différente de concevoir son soft. POINT. Car je n'ai pas encore vu d'atout du C++ qui ne soit pas qu'une "aide" (le mot est mal choisi!) apportée au programmeur C++ comparé au C (implémentable dans une lib par exemple) mis à part la façon de compiler. Mais çà c'est un autre débat et j'ai eut ma dose sur les google groups

C'est surtout à l'usage, lorsqu'on travaille sur de gros projets et, surtout, sur des projets qui deviennent gros avec le temps, que l'intérêt se fait le plus sentir. Je ne compte plus les cas où des projets ont été démarrés en C parce que le paradigme objet est indépendant du langage employé (ce qui est vrai) et qui ont fini par être réécrits en C++ parce que même si le modèle théorique était irréprochable, à l'usage, ça devenait ingérable.

Il s'agit simplement d'utiliser le langage adapté à ce que l'on veut faire, et le plus proche du modèle que l'on a établi : tu pourras toujours te débrouiller pour visser une vis cruciforme avec un tournevis plat, mais si tu prévois d'en visser cent par jour pendant deux mois, il est plus raisonnable d'acheter un tournevis adapté.

[souviron34]

C'est surtout à l'usage, lorsqu'on travaille sur de gros projets et, surtout, sur des projets qui deviennent gros avec le temps, que l'intérêt se fait le plus sentir. Je ne compte plus les cas où des projets ont été démarrés en C parce que le paradigme objet est indépendant du langage employé (ce qui est vrai) et qui ont fini par être réécrits en C++ parce que même si le modèle théorique était irréprochable, à l'usage, ça devenait ingérable.

Je dirais surtout parce que les jeunes ont appris ça à la fin des années 90, et que le gros du dev "à la mode" s'est fait sur Windows avec VisualC++..

Moi qui travaillais sur de très gros projets en environnement industriel ou universtaires pour l'industrie, mais sur unixoides, le C est resté, sauf effet de "jeunisme" des embauchés et nouveaux dirigeants qui ont fait basculer plusieurs projets...

Mais gèrer un très gros projet en C, si il a été bien conçu, est aussi facile et adapté...