Bonjour,
Cela ne fait que très peu de temps que je fais du C, alors même si ma
questions vous semble idiote, pouvez m'aider à comprendre, ou me donner
quelques liens en rapport avec les standards du C.
En effet j'avais l'intention d'acheter le livre : "Le langage C
Norme ANSI" de Brian W. Kernighan et Dennis M. Ritchie (je ne sais pas
si c'est un bon livre...), et j'ai vu que l'on parle de norme et de
standard C, alors je me suis rendu sur la FAQ de développez.com. Il est
écrit :
"Le C est normalisé par l'ISO, la norme du C est donc disponible à
l'achat sur le site de l'ISO (C90, C99) ainsi que sur le site de l'ANSI
(C89). Toutefois son prix reste relativement élevé."
Alors voilà, je me demande ce que cela veut dire, j'ai lu que le livre
cité plus haut utilisait la norme C90. Mais puisque c'est ISO C90, ISO
C99 et ANSI C89, alors pourquoi le livre traite de l'ANSI C90 ? Bref, je
m'embrouille un peu avec tout ça... Je souhaiterais donc obtenir plus
d'information en rapport avec les normes et quels sont leurs différences .
Si on considère que la portabilité, c'est la conformité à un standard, mais c'est aussi la disponiblité de compilateurs, voire d'un choix de compilateurs.
Ta phrase est etrange. Je crois que nous sommes d'accord sur le fond, mais je vais reenfoncer le clou.
La conformite est un moyen pour atteindre la portabilite mais on peut etre portable sans etre conforme et etre conforme ne suffit pas a etre portable.
Je suis tout à fait d'accord. La phrase était étrange parce que connaissant mes tendances à la verbosité je n'ai pas voulu m'étendre sur un sujet qui par ailleurs m'intéresse. Par exemple le fait que si la puissance du C est de bien gérer la portabilité, c'est aussi et peut-être surtout de bien gérer ce qui par essence est non portable, le spécifique. Il me semble que ce sont ces couches interface, typiquement celles de la bibliothèque standard, qui permettent d'écrire au dessus du code portable. Je me trompe peut-être mais il me semble que le C, peut-être le C++, est massivement utilisé pour rendre portable des trucs qui eux le sont vraiment mais ne le seraient pas tout seuls, je pense à Python ou Java par exemple. Je suis dans la plomberie actuellement, je dirais si j'osais que le C est LE "langage mamelon", celui qui permet de passer d'un monde - le système - à un autre - le langage de haut niveau -. Et qui même au sein de ce processus permet de réutiliser la maximum de code, pour peu que la partie spécifique soit clairement identifiée et réduite au minimum vital. Tout ça est assez important à préciser, quand par exemple on est accueilli sur un forum par un adjudantesque "Quelle est la question sur le langage C ?". Quand je vous disais que j'étais verbeux...
-- Pierre Maurette
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
Si on considère que la portabilité, c'est la conformité à un standard,
mais c'est aussi la disponiblité de compilateurs, voire d'un choix de
compilateurs.
Ta phrase est etrange. Je crois que nous sommes d'accord sur le fond, mais
je vais reenfoncer le clou.
La conformite est un moyen pour atteindre la portabilite mais on peut etre
portable sans etre conforme et etre conforme ne suffit pas a etre portable.
Je suis tout à fait d'accord. La phrase était étrange parce que
connaissant mes tendances à la verbosité je n'ai pas voulu m'étendre
sur un sujet qui par ailleurs m'intéresse.
Par exemple le fait que si la puissance du C est de bien gérer la
portabilité, c'est aussi et peut-être surtout de bien gérer ce qui par
essence est non portable, le spécifique.
Il me semble que ce sont ces couches interface, typiquement celles de
la bibliothèque standard, qui permettent d'écrire au dessus du code
portable.
Je me trompe peut-être mais il me semble que le C, peut-être le C++,
est massivement utilisé pour rendre portable des trucs qui eux le sont
vraiment mais ne le seraient pas tout seuls, je pense à Python ou Java
par exemple.
Je suis dans la plomberie actuellement, je dirais si j'osais que le C
est LE "langage mamelon", celui qui permet de passer d'un monde - le
système - à un autre - le langage de haut niveau -. Et qui même au sein
de ce processus permet de réutiliser la maximum de code, pour peu que
la partie spécifique soit clairement identifiée et réduite au minimum
vital.
Tout ça est assez important à préciser, quand par exemple on est
accueilli sur un forum par un adjudantesque "Quelle est la question sur
le langage C ?".
Quand je vous disais que j'étais verbeux...
Si on considère que la portabilité, c'est la conformité à un standard, mais c'est aussi la disponiblité de compilateurs, voire d'un choix de compilateurs.
Ta phrase est etrange. Je crois que nous sommes d'accord sur le fond, mais je vais reenfoncer le clou.
La conformite est un moyen pour atteindre la portabilite mais on peut etre portable sans etre conforme et etre conforme ne suffit pas a etre portable.
Je suis tout à fait d'accord. La phrase était étrange parce que connaissant mes tendances à la verbosité je n'ai pas voulu m'étendre sur un sujet qui par ailleurs m'intéresse. Par exemple le fait que si la puissance du C est de bien gérer la portabilité, c'est aussi et peut-être surtout de bien gérer ce qui par essence est non portable, le spécifique. Il me semble que ce sont ces couches interface, typiquement celles de la bibliothèque standard, qui permettent d'écrire au dessus du code portable. Je me trompe peut-être mais il me semble que le C, peut-être le C++, est massivement utilisé pour rendre portable des trucs qui eux le sont vraiment mais ne le seraient pas tout seuls, je pense à Python ou Java par exemple. Je suis dans la plomberie actuellement, je dirais si j'osais que le C est LE "langage mamelon", celui qui permet de passer d'un monde - le système - à un autre - le langage de haut niveau -. Et qui même au sein de ce processus permet de réutiliser la maximum de code, pour peu que la partie spécifique soit clairement identifiée et réduite au minimum vital. Tout ça est assez important à préciser, quand par exemple on est accueilli sur un forum par un adjudantesque "Quelle est la question sur le langage C ?". Quand je vous disais que j'étais verbeux...
-- Pierre Maurette
espie
In article , Jean-Marc Bourguet wrote:
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue pour etre reellement pertinente dans la plupart des niches ou le C est important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
In article <pxbmypblz22.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue
pour etre reellement pertinente dans la plupart des niches ou le C est
important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont
assez repandus pour etre utilisables, ou pour qu'on utilise maintenant
systematiquement les noms preconises par celles-ci (je pense bien
evidemment a stdint.h).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de
conversion de caracteres sont maintenant egalement bien passees dans les
moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant
C99, dans un ajout a C89).
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue pour etre reellement pertinente dans la plupart des niches ou le C est important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
Jean-Marc Bourguet
(Marc Espie) writes:
In article , Jean-Marc Bourguet wrote:
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue pour etre reellement pertinente dans la plupart des niches ou le C est important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
J'ai effectivement un peu simplifie la situation pour ne pas embrouiller un peu plus David. Je suis d'accord, dans chaque niche, ce qui est pertinent c'est un etat intermediaire entre C90 et C99. Unix etant vraissemblablement la niche la plus proche du C99 car POSIX est base sur C99 et le desir de conformance a cette norme est une pression supplementaire.
Les autres niches importantes (l'embarque, la tres large portabilite) sont nettement moins avancees (presque par definition pour la tres large portabilite).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois. Est-ce que quelqu'un sait ou trouver les documents de cet amendement?).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
In article <pxbmypblz22.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue
pour etre reellement pertinente dans la plupart des niches ou le C est
important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont
assez repandus pour etre utilisables, ou pour qu'on utilise maintenant
systematiquement les noms preconises par celles-ci (je pense bien
evidemment a stdint.h).
J'ai effectivement un peu simplifie la situation pour ne pas embrouiller un
peu plus David. Je suis d'accord, dans chaque niche, ce qui est pertinent
c'est un etat intermediaire entre C90 et C99. Unix etant
vraissemblablement la niche la plus proche du C99 car POSIX est base sur
C99 et le desir de conformance a cette norme est une pression
supplementaire.
Les autres niches importantes (l'embarque, la tres large portabilite) sont
nettement moins avancees (presque par definition pour la tres large
portabilite).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de
conversion de caracteres sont maintenant egalement bien passees dans les
moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant
C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois.
Est-ce que quelqu'un sait ou trouver les documents de cet amendement?).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
La norme C99 n'est pas mauvaise, elle n'est simplement pas assez repandue pour etre reellement pertinente dans la plupart des niches ou le C est important.
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
J'ai effectivement un peu simplifie la situation pour ne pas embrouiller un peu plus David. Je suis d'accord, dans chaque niche, ce qui est pertinent c'est un etat intermediaire entre C90 et C99. Unix etant vraissemblablement la niche la plus proche du C99 car POSIX est base sur C99 et le desir de conformance a cette norme est une pression supplementaire.
Les autres niches importantes (l'embarque, la tres large portabilite) sont nettement moins avancees (presque par definition pour la tres large portabilite).
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois. Est-ce que quelqu'un sait ou trouver les documents de cet amendement?).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette
[...]
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
Effectivement, j'utilise beaucoup. Pour MSVC: <URL:http://msinttypes.googlecode.com/svn/trunk/stdint.h> <URL:http://msinttypes.googlecode.com/svn/trunk/inttypes.h>
-- Pierre Maurette
[...]
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont
assez repandus pour etre utilisables, ou pour qu'on utilise maintenant
systematiquement les noms preconises par celles-ci (je pense bien
evidemment a stdint.h).
Effectivement, j'utilise beaucoup.
Pour MSVC:
<URL:http://msinttypes.googlecode.com/svn/trunk/stdint.h>
<URL:http://msinttypes.googlecode.com/svn/trunk/inttypes.h>
Bof, les choses changent quand meme. Il y a des pans de C99 qui sont assez repandus pour etre utilisables, ou pour qu'on utilise maintenant systematiquement les noms preconises par celles-ci (je pense bien evidemment a stdint.h).
Effectivement, j'utilise beaucoup. Pour MSVC: <URL:http://msinttypes.googlecode.com/svn/trunk/stdint.h> <URL:http://msinttypes.googlecode.com/svn/trunk/inttypes.h>
-- Pierre Maurette
Antoine Leca
En news:47d0679f$0$846$, Sylvain va escriure:
le C est standardisé depuis "relativement peu" de temps.
Tout est relatif.
Le langage a été inventé en 1971 ± 1 année. Les premières implémentations stables (c'est-à-dire utilisables par quelqu'un d'autre que les développeurs eux-mêmes, on dirait aujourd'hui de qualité bêta) datent de la V5 de Unix, soit 1974. Fixons l'origine à cette année-là.
Le premier standard réel (le K&R 1re version) date de 1978 (A+4).
La première norme a peînée à voir le jour, et même si le texte de 1986 est « quasi-définitif », il a fallu attendre 1989 (A+15) pour la voir sortir officiellement sous le nom de norme ANSI. Les changements étaient substanciels par rapport au précédent standard, ce qui fait que les deux standards ont cohabités ouvertement pendant plusieurs années (disons 10 ans ; même si encore aujourd'hui on peut trouver des programmeurs pour K&R, c'est devenu très anecdotique).
La première norme internationale (ISO) est quasiment identique à la précédente, elle date de 1990 (A+16). Elle a été améliorée à la marge en 1995, sans effet probant. Elle a été révisée en 1999 (A+25), mais de l'avis général cette révision ne s'est pas imposée comme primordiale, donc les deux continuent de cohabiter encore à l'heure actuelle sans que cela se remarque à première vue.
Une prochaine révision de la norme est prévue pour 2011 ou 2012.
Donc, si on se place en 2008 (A+34), le langage a été standardisé il y a 30 ans, et normalisé il y a 19 ans. C'est en effet relativement peu, par rapport au calendrier grégorien, à l'imprimerie ou à la Bible.
Antoine
En news:47d0679f$0$846$ba4acef3@news.orange.fr, Sylvain va escriure:
le C est standardisé depuis "relativement peu" de temps.
Tout est relatif.
Le langage a été inventé en 1971 ± 1 année. Les premières implémentations
stables (c'est-à-dire utilisables par quelqu'un d'autre que les développeurs
eux-mêmes, on dirait aujourd'hui de qualité bêta) datent de la V5 de Unix,
soit 1974. Fixons l'origine à cette année-là.
Le premier standard réel (le K&R 1re version) date de 1978 (A+4).
La première norme a peînée à voir le jour, et même si le texte de 1986 est
« quasi-définitif », il a fallu attendre 1989 (A+15) pour la voir sortir
officiellement sous le nom de norme ANSI. Les changements étaient
substanciels par rapport au précédent standard, ce qui fait que les deux
standards ont cohabités ouvertement pendant plusieurs années (disons 10 ans
; même si encore aujourd'hui on peut trouver des programmeurs pour K&R,
c'est devenu très anecdotique).
La première norme internationale (ISO) est quasiment identique à la
précédente, elle date de 1990 (A+16).
Elle a été améliorée à la marge en 1995, sans effet probant.
Elle a été révisée en 1999 (A+25), mais de l'avis général cette révision ne
s'est pas imposée comme primordiale, donc les deux continuent de cohabiter
encore à l'heure actuelle sans que cela se remarque à première vue.
Une prochaine révision de la norme est prévue pour 2011 ou 2012.
Donc, si on se place en 2008 (A+34), le langage a été standardisé il y a 30
ans, et normalisé il y a 19 ans.
C'est en effet relativement peu, par rapport au calendrier grégorien, à
l'imprimerie ou à la Bible.
le C est standardisé depuis "relativement peu" de temps.
Tout est relatif.
Le langage a été inventé en 1971 ± 1 année. Les premières implémentations stables (c'est-à-dire utilisables par quelqu'un d'autre que les développeurs eux-mêmes, on dirait aujourd'hui de qualité bêta) datent de la V5 de Unix, soit 1974. Fixons l'origine à cette année-là.
Le premier standard réel (le K&R 1re version) date de 1978 (A+4).
La première norme a peînée à voir le jour, et même si le texte de 1986 est « quasi-définitif », il a fallu attendre 1989 (A+15) pour la voir sortir officiellement sous le nom de norme ANSI. Les changements étaient substanciels par rapport au précédent standard, ce qui fait que les deux standards ont cohabités ouvertement pendant plusieurs années (disons 10 ans ; même si encore aujourd'hui on peut trouver des programmeurs pour K&R, c'est devenu très anecdotique).
La première norme internationale (ISO) est quasiment identique à la précédente, elle date de 1990 (A+16). Elle a été améliorée à la marge en 1995, sans effet probant. Elle a été révisée en 1999 (A+25), mais de l'avis général cette révision ne s'est pas imposée comme primordiale, donc les deux continuent de cohabiter encore à l'heure actuelle sans que cela se remarque à première vue.
Une prochaine révision de la norme est prévue pour 2011 ou 2012.
Donc, si on se place en 2008 (A+34), le langage a été standardisé il y a 30 ans, et normalisé il y a 19 ans. C'est en effet relativement peu, par rapport au calendrier grégorien, à l'imprimerie ou à la Bible.
Antoine
Antoine Leca
En news:, Jean-Marc Bourguet va escriure:
Marc Espie writes:
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois.
Oui. On trouve aussi le nom MSE (/Multibyte Support Extension/), qui fut le nom de code de ce projet lors de son élaboration au début des années 1990. Officellement c'est ISO/CEI 9899:1990/Amendment 1:1995(E)
Est-ce que quelqu'un sait ou trouver les documents de cet amendement?).
Malheureusement, la seule méthode que je connaisse est de l'acheter :-( Il doit être encore dispo à l'AFNOR, c'est l'Amd.1:1996 à EN 29899:1993 dans les annales AFNOR (indice de classement Z65-130) ; mais il n'est semble-t-il plus au catalogue, officiellement ils sont passés eux aussi à C99.
Le plus approchant en librement disponible, c'est de consulter le premier brouillon librement accessible (numéroté N794) de C9X, et de faire la différence au niveau de la clause 7.13 par rapport à C90, et de reprendre les clauses 7.17, 7.18 et 7.19 ajoutées par C95 : on retrouve une bonne partie du texte normatif de MSE.
La partie « Rationale » s'est pour sa part retrouvée intégrée dans le Rationale de C99 (de mémoire il y a un chapitre dédié au sujet des caractères larges, qui reprend en fait le prémbule de MSE). Utile à lire au moins une fois.
Antoine
En news:pxbiqzyziog.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
Marc Espie writes:
Pour les gens qui font de l'internationalisation, les fonctions `a
etat' de conversion de caracteres sont maintenant egalement bien
passees dans les moeurs (si ma memoire est bonne, elles ont
d'ailleurs ete definies avant C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois.
Oui.
On trouve aussi le nom MSE (/Multibyte Support Extension/), qui fut le nom
de code de ce projet lors de son élaboration au début des années 1990.
Officellement c'est ISO/CEI 9899:1990/Amendment 1:1995(E)
Est-ce que quelqu'un sait ou trouver les documents de cet
amendement?).
Malheureusement, la seule méthode que je connaisse est de l'acheter :-(
Il doit être encore dispo à l'AFNOR, c'est l'Amd.1:1996 à EN 29899:1993 dans
les annales AFNOR (indice de classement Z65-130) ; mais il n'est semble-t-il
plus au catalogue, officiellement ils sont passés eux aussi à C99.
Le plus approchant en librement disponible, c'est de consulter le premier
brouillon librement accessible (numéroté N794) de C9X, et de faire la
différence au niveau de la clause 7.13 par rapport à C90, et de reprendre
les clauses 7.17, 7.18 et 7.19 ajoutées par C95 : on retrouve une bonne
partie du texte normatif de MSE.
La partie « Rationale » s'est pour sa part retrouvée intégrée dans le
Rationale de C99 (de mémoire il y a un chapitre dédié au sujet des
caractères larges, qui reprend en fait le prémbule de MSE). Utile à lire au
moins une fois.
Pour les gens qui font de l'internationalisation, les fonctions `a etat' de conversion de caracteres sont maintenant egalement bien passees dans les moeurs (si ma memoire est bonne, elles ont d'ailleurs ete definies avant C99, dans un ajout a C89).
C'est ce que je pense aussi. (C'est le C95 qu'on rencontre parfois.
Oui. On trouve aussi le nom MSE (/Multibyte Support Extension/), qui fut le nom de code de ce projet lors de son élaboration au début des années 1990. Officellement c'est ISO/CEI 9899:1990/Amendment 1:1995(E)
Est-ce que quelqu'un sait ou trouver les documents de cet amendement?).
Malheureusement, la seule méthode que je connaisse est de l'acheter :-( Il doit être encore dispo à l'AFNOR, c'est l'Amd.1:1996 à EN 29899:1993 dans les annales AFNOR (indice de classement Z65-130) ; mais il n'est semble-t-il plus au catalogue, officiellement ils sont passés eux aussi à C99.
Le plus approchant en librement disponible, c'est de consulter le premier brouillon librement accessible (numéroté N794) de C9X, et de faire la différence au niveau de la clause 7.13 par rapport à C90, et de reprendre les clauses 7.17, 7.18 et 7.19 ajoutées par C95 : on retrouve une bonne partie du texte normatif de MSE.
La partie « Rationale » s'est pour sa part retrouvée intégrée dans le Rationale de C99 (de mémoire il y a un chapitre dédié au sujet des caractères larges, qui reprend en fait le prémbule de MSE). Utile à lire au moins une fois.
