j'ai edité sous kwrite le programme suivant qu'on trouve ici
http://lea-linux.org/dev/libc.html#intro en bas de page .
lorsque je le compile "gcc -o test test.c tri_a_bulles.c "
j'obtiens les messages d'erreurs suivant:
In file included from test.c:3:
tri_a_bulles.h:9:7: warning: no newline at end of file
test.c:26:2: warning: no newline at end of file
In file included from tri_a_bulles.c:1:
tri_a_bulles.h:9:7: warning: no newline at end of file
tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si
graves . A quoi sont elles dues et comment les eviter
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
fabrizio
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si graves . A quoi sont elles dues et comment les eviter ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
In file included from test.c:3:
tri_a_bulles.h:9:7: warning: no newline at end of file
test.c:26:2: warning: no newline at end of file
In file included from tri_a_bulles.c:1:
tri_a_bulles.h:9:7: warning: no newline at end of file
tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si
graves . A quoi sont elles dues et comment les eviter
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers
je n'en connais pas la raison mais gcc affiche un warning si
la derniere ligne des fichiers sources n'est pas vide
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si graves . A quoi sont elles dues et comment les eviter ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
bob
fabrizio wrote:
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers
Okay je viens de les ajouter et il ne m'indique plus de warnings lors de la compilation
je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
merci pour l'info .
fabrizio wrote:
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers
Okay je viens de les ajouter et il ne m'indique plus de warnings lors
de la compilation
je n'en connais pas la raison mais gcc affiche un warning si
la derniere ligne des fichiers sources n'est pas vide
Okay je viens de les ajouter et il ne m'indique plus de warnings lors de la compilation
je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
merci pour l'info .
James Kanze
fabrizio wrote:
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si graves . A quoi sont elles dues et comment les eviter
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
fabrizio wrote:
In file included from test.c:3:
tri_a_bulles.h:9:7: warning: no newline at end of file
test.c:26:2: warning: no newline at end of file
In file included from tri_a_bulles.c:1:
tri_a_bulles.h:9:7: warning: no newline at end of file
tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont
pas si graves . A quoi sont elles dues et comment les eviter
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers
je n'en connais pas la raison mais gcc affiche un warning si
la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier
caractère d'un fichier source doit toujours être un 'n' non
précéder d'un '\' y est pour quelque chose.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
.Le programme test marche quand même donc ces erreurs sont pas si graves . A quoi sont elles dues et comment les eviter
ce n'est pas des erreurs mais des warnings...
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Erwann ABALEA
On Mon, 31 Jan 2005, James Kanze wrote:
fabrizio wrote:
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est définie comme une suite de caractères terminée par un caractère de fin de ligne ('n'). Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait partie de la ligne de texte. La dernière ligne d'un fichier texte est elle aussi une ligne de texte, donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte était définie comme tel.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Il y a un festnoz retransmis en realaudio. La transmission est, sauf erreur assurée par oleane:impossible d'avoir image ou son...Que passa ???? Trop de bretons connectés en même temps ? Ou bien pb avec ci ??? -+-TS in : GNU - Ils ont plein de connexions, vive la bretagne -+-
On Mon, 31 Jan 2005, James Kanze wrote:
fabrizio wrote:
In file included from test.c:3:
tri_a_bulles.h:9:7: warning: no newline at end of file
test.c:26:2: warning: no newline at end of file
In file included from tri_a_bulles.c:1:
tri_a_bulles.h:9:7: warning: no newline at end of file
tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers
je n'en connais pas la raison mais gcc affiche un warning si
la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier
caractère d'un fichier source doit toujours être un 'n' non
précéder d'un '\' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est définie comme
une suite de caractères terminée par un caractère de fin de ligne ('n').
Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait
partie de la ligne de texte.
La dernière ligne d'un fichier texte est elle aussi une ligne de texte,
donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte était définie
comme tel.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Il y a un festnoz retransmis en realaudio. La transmission est, sauf erreur
assurée par oleane:impossible d'avoir image ou son...Que passa ????
Trop de bretons connectés en même temps ? Ou bien pb avec ci ???
-+-TS in : GNU - Ils ont plein de connexions, vive la bretagne -+-
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est définie comme une suite de caractères terminée par un caractère de fin de ligne ('n'). Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait partie de la ligne de texte. La dernière ligne d'un fichier texte est elle aussi une ligne de texte, donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte était définie comme tel.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Il y a un festnoz retransmis en realaudio. La transmission est, sauf erreur assurée par oleane:impossible d'avoir image ou son...Que passa ???? Trop de bretons connectés en même temps ? Ou bien pb avec ci ??? -+-TS in : GNU - Ils ont plein de connexions, vive la bretagne -+-
Gabriel Dos Reis
Erwann ABALEA writes:
| On Mon, 31 Jan 2005, James Kanze wrote: | | > fabrizio wrote: | > >> In file included from test.c:3: | > >> tri_a_bulles.h:9:7: warning: no newline at end of file | > >> test.c:26:2: warning: no newline at end of file | > >> In file included from tri_a_bulles.c:1: | > >> tri_a_bulles.h:9:7: warning: no newline at end of file | > >> tri_a_bulles.c:36:2: warning: no newline at end of file | > | > > il manque un retour chariot à la fin des fichiers | > > je n'en connais pas la raison mais gcc affiche un warning si | > > la derniere ligne des fichiers sources n'est pas vide | > | > Je me démande si le fait que la norme dit que le dernier | > caractère d'un fichier source doit toujours être un 'n' non | > précéder d'un '' y est pour quelque chose. | | Je dirais que c'est logique. Souvent une ligne de texte est définie comme | une suite de caractères terminée par un caractère de fin de ligne ('n'). | Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait | partie de la ligne de texte. | La dernière ligne d'un fichier texte est elle aussi une ligne de texte, | donc doit aussi avoir son 'n' final. | | Je n'ai pas lu la norme pour savoir si une ligne de texte était définie | comme tel.
Pas exactement, mais la spécification de Cpp est telle que 'n' joue un rôle capital.
2.1/2 Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. If, as a result, a character sequence that matches the syntax of a universal-character-name is produced, the behavior is undefined. If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character, the behavior is undefined.
-- Gaby
Erwann ABALEA <erwann@abalea.com> writes:
| On Mon, 31 Jan 2005, James Kanze wrote:
|
| > fabrizio wrote:
| > >> In file included from test.c:3:
| > >> tri_a_bulles.h:9:7: warning: no newline at end of file
| > >> test.c:26:2: warning: no newline at end of file
| > >> In file included from tri_a_bulles.c:1:
| > >> tri_a_bulles.h:9:7: warning: no newline at end of file
| > >> tri_a_bulles.c:36:2: warning: no newline at end of file
| >
| > > il manque un retour chariot à la fin des fichiers
| > > je n'en connais pas la raison mais gcc affiche un warning si
| > > la derniere ligne des fichiers sources n'est pas vide
| >
| > Je me démande si le fait que la norme dit que le dernier
| > caractère d'un fichier source doit toujours être un 'n' non
| > précéder d'un '\' y est pour quelque chose.
|
| Je dirais que c'est logique. Souvent une ligne de texte est définie comme
| une suite de caractères terminée par un caractère de fin de ligne ('n').
| Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait
| partie de la ligne de texte.
| La dernière ligne d'un fichier texte est elle aussi une ligne de texte,
| donc doit aussi avoir son 'n' final.
|
| Je n'ai pas lu la norme pour savoir si une ligne de texte était définie
| comme tel.
Pas exactement, mais la spécification de Cpp est telle que 'n' joue
un rôle capital.
2.1/2
Each instance of a new-line character and an immediately preceding
backslash character is deleted, splicing physical source lines to
form logical source lines. If, as a result, a character sequence
that matches the syntax of a universal-character-name is produced,
the behavior is undefined. If a source file that is not empty does
not end in a new-line character, or ends in a new-line character
immediately preceded by a backslash character, the behavior is
undefined.
| On Mon, 31 Jan 2005, James Kanze wrote: | | > fabrizio wrote: | > >> In file included from test.c:3: | > >> tri_a_bulles.h:9:7: warning: no newline at end of file | > >> test.c:26:2: warning: no newline at end of file | > >> In file included from tri_a_bulles.c:1: | > >> tri_a_bulles.h:9:7: warning: no newline at end of file | > >> tri_a_bulles.c:36:2: warning: no newline at end of file | > | > > il manque un retour chariot à la fin des fichiers | > > je n'en connais pas la raison mais gcc affiche un warning si | > > la derniere ligne des fichiers sources n'est pas vide | > | > Je me démande si le fait que la norme dit que le dernier | > caractère d'un fichier source doit toujours être un 'n' non | > précéder d'un '' y est pour quelque chose. | | Je dirais que c'est logique. Souvent une ligne de texte est définie comme | une suite de caractères terminée par un caractère de fin de ligne ('n'). | Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait | partie de la ligne de texte. | La dernière ligne d'un fichier texte est elle aussi une ligne de texte, | donc doit aussi avoir son 'n' final. | | Je n'ai pas lu la norme pour savoir si une ligne de texte était définie | comme tel.
Pas exactement, mais la spécification de Cpp est telle que 'n' joue un rôle capital.
2.1/2 Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. If, as a result, a character sequence that matches the syntax of a universal-character-name is produced, the behavior is undefined. If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character, the behavior is undefined.
-- Gaby
kanze
Erwann ABALEA wrote:
On Mon, 31 Jan 2005, James Kanze wrote:
fabrizio wrote:
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est définie comme une suite de caractères terminée par un caractère de fin de ligne ('n'). Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait partie de la ligne de texte. La dernière ligne d'un fichier texte est elle aussi une ligne de texte, donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte était définie comme tel.
La définition d'une ligne dans un fichier (y compris dans un fichier source) dépend de l'implémentation -- ça peut être des caractères terminés par un LF, des caractères terminés par un CR, LF (selon la norme ASCII), ou n'importe quoi d'autre, y compris de la structure sur disque. Mais la première chose que le compilateur est sensé faire, c'est mapper la représentation externe des caractères en représentation interne, y compris remplacer l'indication externe de fin de ligne par un 'n'.
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier -- de même un compilateur Unix pourrait accepter CR, LF, en le définissant d'être l'équivalent à 'n'. Mais je ne suis pas convaincu d'une telle interprétation soit réelement dans l'intérêt du programmeur, dans la mésure que ce sont des conventions peu habituelles sous Unix. (Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Erwann ABALEA wrote:
On Mon, 31 Jan 2005, James Kanze wrote:
fabrizio wrote:
In file included from test.c:3:
tri_a_bulles.h:9:7: warning: no newline at end of file
test.c:26:2: warning: no newline at end of file
In file included from tri_a_bulles.c:1:
tri_a_bulles.h:9:7: warning: no newline at end of file
tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers je n'en
connais pas la raison mais gcc affiche un warning si la
derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier
caractère d'un fichier source doit toujours être un 'n' non
précéder d'un '\' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est
définie comme une suite de caractères terminée par un
caractère de fin de ligne ('n'). Dans ce cas précis, la fin
de ligne n'est pas un séparateur, mais fait partie de la ligne
de texte. La dernière ligne d'un fichier texte est elle aussi
une ligne de texte, donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte
était définie comme tel.
La définition d'une ligne dans un fichier (y compris dans un
fichier source) dépend de l'implémentation -- ça peut être des
caractères terminés par un LF, des caractères terminés par un
CR, LF (selon la norme ASCII), ou n'importe quoi d'autre, y
compris de la structure sur disque. Mais la première chose que
le compilateur est sensé faire, c'est mapper la représentation
externe des caractères en représentation interne, y compris
remplacer l'indication externe de fin de ligne par un 'n'.
Du coup, rien n'intérdit à un compilateur sous Unix de dire que
la représentation de la fin de ligne dans une source, c'est soit
un 'n', soit la fin de fichier -- de même un compilateur Unix
pourrait accepter CR, LF, en le définissant d'être l'équivalent
à 'n'. Mais je ne suis pas convaincu d'une telle interprétation
soit réelement dans l'intérêt du programmeur, dans la mésure que
ce sont des conventions peu habituelles sous Unix. (Il serait
intéressant de supporter le CR, LF comme option, en plus. Mais
comme extension, non comme partie du C++ standard.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
In file included from test.c:3: tri_a_bulles.h:9:7: warning: no newline at end of file test.c:26:2: warning: no newline at end of file In file included from tri_a_bulles.c:1: tri_a_bulles.h:9:7: warning: no newline at end of file tri_a_bulles.c:36:2: warning: no newline at end of file
il manque un retour chariot à la fin des fichiers je n'en connais pas la raison mais gcc affiche un warning si la derniere ligne des fichiers sources n'est pas vide
Je me démande si le fait que la norme dit que le dernier caractère d'un fichier source doit toujours être un 'n' non précéder d'un '' y est pour quelque chose.
Je dirais que c'est logique. Souvent une ligne de texte est définie comme une suite de caractères terminée par un caractère de fin de ligne ('n'). Dans ce cas précis, la fin de ligne n'est pas un séparateur, mais fait partie de la ligne de texte. La dernière ligne d'un fichier texte est elle aussi une ligne de texte, donc doit aussi avoir son 'n' final.
Je n'ai pas lu la norme pour savoir si une ligne de texte était définie comme tel.
La définition d'une ligne dans un fichier (y compris dans un fichier source) dépend de l'implémentation -- ça peut être des caractères terminés par un LF, des caractères terminés par un CR, LF (selon la norme ASCII), ou n'importe quoi d'autre, y compris de la structure sur disque. Mais la première chose que le compilateur est sensé faire, c'est mapper la représentation externe des caractères en représentation interne, y compris remplacer l'indication externe de fin de ligne par un 'n'.
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier -- de même un compilateur Unix pourrait accepter CR, LF, en le définissant d'être l'équivalent à 'n'. Mais je ne suis pas convaincu d'une telle interprétation soit réelement dans l'intérêt du programmeur, dans la mésure que ce sont des conventions peu habituelles sous Unix. (Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 31 Jan 2005 23:45:55 -0800, :
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier [...] (Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
Je ne comprends pas bien ce que la notion de C++ standard vient faire dans la traduction [code sur disque dur]->[code en mémoire].
-- ;-)
On 31 Jan 2005 23:45:55 -0800, kanze@gabi-soft.fr:
Du coup, rien n'intérdit à un compilateur sous Unix de dire que
la représentation de la fin de ligne dans une source, c'est soit
un 'n', soit la fin de fichier [...]
(Il serait
intéressant de supporter le CR, LF comme option, en plus. Mais
comme extension, non comme partie du C++ standard.)
Je ne comprends pas bien ce que la notion de C++ standard vient faire
dans la traduction [code sur disque dur]->[code en mémoire].
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier [...] (Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
Je ne comprends pas bien ce que la notion de C++ standard vient faire dans la traduction [code sur disque dur]->[code en mémoire].
-- ;-)
kanze
Fabien LE LEZ wrote:
On 31 Jan 2005 23:45:55 -0800, :
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier [...]
(Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
Je ne comprends pas bien ce que la notion de C++ standard vient faire dans la traduction [code sur disque dur]->[code en mémoire].
La norme dit qu'il doit avoir lieu. Et que c'est défini par l'implémentation. Dans la pratique, l'intention semble que la traduction se fait selon les règles habituelles de l'environement, à peu près comme si le compilateur lisait un fichier ouvert en mode texte.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 31 Jan 2005 23:45:55 -0800, kanze@gabi-soft.fr:
Du coup, rien n'intérdit à un compilateur sous Unix de dire
que la représentation de la fin de ligne dans une source,
c'est soit un 'n', soit la fin de fichier [...]
(Il serait intéressant de supporter le CR, LF comme option,
en plus. Mais comme extension, non comme partie du C++
standard.)
Je ne comprends pas bien ce que la notion de C++ standard
vient faire dans la traduction [code sur disque dur]->[code en
mémoire].
La norme dit qu'il doit avoir lieu. Et que c'est défini par
l'implémentation. Dans la pratique, l'intention semble que la
traduction se fait selon les règles habituelles de
l'environement, à peu près comme si le compilateur lisait un
fichier ouvert en mode texte.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Du coup, rien n'intérdit à un compilateur sous Unix de dire que la représentation de la fin de ligne dans une source, c'est soit un 'n', soit la fin de fichier [...]
(Il serait intéressant de supporter le CR, LF comme option, en plus. Mais comme extension, non comme partie du C++ standard.)
Je ne comprends pas bien ce que la notion de C++ standard vient faire dans la traduction [code sur disque dur]->[code en mémoire].
La norme dit qu'il doit avoir lieu. Et que c'est défini par l'implémentation. Dans la pratique, l'intention semble que la traduction se fait selon les règles habituelles de l'environement, à peu près comme si le compilateur lisait un fichier ouvert en mode texte.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
