A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je n'ai _jamais_ eu dans les main un système préfixe. Quel chanceux vous êtes.
Je voulais dire postfixe. Le lecteur attentif aura rectifié de lui-même.
Oui, mais en langage informatique. De toute façon, même en mathématiques, un vecteur n'est pas une fonction (tout au plus une fonction échantillonnée). Pipo.
Votre argumentation est très constructive lorsque vous ne pouvez
plus rien dire.
Eh bien puisqu'il faut expliquer, expliquons. Déjà, mathématiquement, un tableau est une fonction, avec une partie de l'ensemble des entiers naturels comme domaine de définition.
Un vecteur est bien plus que cela, mais si vous voulez restreindre un vecteur ou un tableau à cela, libre à vous.
Ensuite, et surtout, pour un langage informatique, il n'y a pas de différence fondamentale entre l'accès à un élément d'un tableau, et l'appel d'une fonction.
En algorithmie, d'accord. Mais pas dans un _vrai_ langage !
Dans les deux cas, il s'agit de rentrer un nombre, et d'obtenir un résultat en retour. Le tableau est un cas particulier de la fonction où le calcul est directement développé.
Non. Si le résultat est le même, la procédure est totalement différente.
D'ailleurs, certains langages permettent de redéfinir la notation de tableaux sur des objets, pour utiliser n'importe quelle fonction derrière.
Et alors ? Ca prouve justement qu'il y a une différence _fondamentale_ entre un tableau et une simple fonction échantillonnée fut-ce sur les entiers positifs.
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce5b91.285.bertrand@grossebaf.systella.fr>, a
écrit :
Je n'ai _jamais_ eu dans les main un système préfixe. Quel chanceux
vous êtes.
Je voulais dire postfixe. Le lecteur attentif aura rectifié de lui-même.
Oui, mais en langage informatique. De toute façon, même en
mathématiques, un vecteur n'est pas une fonction (tout au plus une
fonction échantillonnée).
Pipo.
Votre argumentation est très constructive lorsque vous ne pouvez
plus rien dire.
Eh bien puisqu'il faut expliquer, expliquons. Déjà, mathématiquement, un
tableau est une fonction, avec une partie de l'ensemble des entiers
naturels comme domaine de définition.
Un vecteur est bien plus que cela, mais si vous voulez restreindre
un vecteur ou un tableau à cela, libre à vous.
Ensuite, et surtout, pour un langage informatique, il n'y a pas de
différence fondamentale entre l'accès à un élément d'un tableau, et
l'appel d'une fonction.
En algorithmie, d'accord. Mais pas dans un _vrai_ langage !
Dans les deux cas, il s'agit de rentrer un
nombre, et d'obtenir un résultat en retour. Le tableau est un cas
particulier de la fonction où le calcul est directement développé.
Non. Si le résultat est le même, la procédure est totalement
différente.
D'ailleurs, certains langages permettent de redéfinir la notation de
tableaux sur des objets, pour utiliser n'importe quelle fonction
derrière.
Et alors ? Ca prouve justement qu'il y a une différence
_fondamentale_ entre un tableau et une simple fonction
échantillonnée fut-ce sur les entiers positifs.
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Je n'ai _jamais_ eu dans les main un système préfixe. Quel chanceux vous êtes.
Je voulais dire postfixe. Le lecteur attentif aura rectifié de lui-même.
Oui, mais en langage informatique. De toute façon, même en mathématiques, un vecteur n'est pas une fonction (tout au plus une fonction échantillonnée). Pipo.
Votre argumentation est très constructive lorsque vous ne pouvez
plus rien dire.
Eh bien puisqu'il faut expliquer, expliquons. Déjà, mathématiquement, un tableau est une fonction, avec une partie de l'ensemble des entiers naturels comme domaine de définition.
Un vecteur est bien plus que cela, mais si vous voulez restreindre un vecteur ou un tableau à cela, libre à vous.
Ensuite, et surtout, pour un langage informatique, il n'y a pas de différence fondamentale entre l'accès à un élément d'un tableau, et l'appel d'une fonction.
En algorithmie, d'accord. Mais pas dans un _vrai_ langage !
Dans les deux cas, il s'agit de rentrer un nombre, et d'obtenir un résultat en retour. Le tableau est un cas particulier de la fonction où le calcul est directement développé.
Non. Si le résultat est le même, la procédure est totalement différente.
D'ailleurs, certains langages permettent de redéfinir la notation de tableaux sur des objets, pour utiliser n'importe quelle fonction derrière.
Et alors ? Ca prouve justement qu'il y a une différence _fondamentale_ entre un tableau et une simple fonction échantillonnée fut-ce sur les entiers positifs.
JKB
Richard Delorme
Bref il s'agissait de créer un langage de haut niveau, en partant de langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a layer of thin glue over computer hardware approximating the "standard architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR : http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
Quand ESR écrit (dans le chapitre 4) : « Thompson and Ritchie designed C to be a sort of structured assembler », je pense qu'il utilise une antinomie (structuré et assembleur sont bien sûr contradictoires) pour insister sur le fait que le langage C est proche de la machine. Un point sur lequel le C est proche de la machine, par exemple, est la tailles des types entiers. Le type de base char peut faire 8 bits, 9 bits, 24 bits, 32 bits, etc. selon l'implémentation. A contrario, un langage comme Java, qui prend ses distances du matériel grâce à sa machine virtuelle, a des types de tailles fixes (byte : 8 bits, short 16 bits, etc.). Cette proximité avec la machine facilite l'implémentation du langage C et en explique sans doute le succès. Mais ça ne fait pas du C un assembleur. Le langage C est un langage de haut niveau, structuré, déclaratif et récursif, de 3ème génération (3GL), difficilement comparable au langage de 2ème génération qu'est l'assembleur. La brique du langage d'assemblage est l'instruction, or ce concept n'existe pas dans le langage C, qui manipule des objets, des fonctions, des expressions, mais pas d'instructions. Bref, il s'agit de deux langages fondamentalement différents et toutes les boutades qui les comparent sont généralement absurdes.
-- Richard
Bref il s'agissait de créer un langage de haut niveau, en partant de
langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a
layer of thin glue over computer hardware approximating the "standard
architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR :
http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
Quand ESR écrit (dans le chapitre 4) : « Thompson and Ritchie designed C
to be a sort of structured assembler », je pense qu'il utilise une
antinomie (structuré et assembleur sont bien sûr contradictoires) pour
insister sur le fait que le langage C est proche de la machine.
Un point sur lequel le C est proche de la machine, par exemple, est la
tailles des types entiers. Le type de base char peut faire 8 bits, 9
bits, 24 bits, 32 bits, etc. selon l'implémentation. A contrario, un
langage comme Java, qui prend ses distances du matériel grâce à sa
machine virtuelle, a des types de tailles fixes (byte : 8 bits, short 16
bits, etc.). Cette proximité avec la machine facilite l'implémentation
du langage C et en explique sans doute le succès.
Mais ça ne fait pas du C un assembleur. Le langage C est un langage de
haut niveau, structuré, déclaratif et récursif, de 3ème génération
(3GL), difficilement comparable au langage de 2ème génération qu'est
l'assembleur. La brique du langage d'assemblage est l'instruction, or ce
concept n'existe pas dans le langage C, qui manipule des objets, des
fonctions, des expressions, mais pas d'instructions. Bref, il s'agit de
deux langages fondamentalement différents et toutes les boutades qui les
comparent sont généralement absurdes.
Bref il s'agissait de créer un langage de haut niveau, en partant de langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a layer of thin glue over computer hardware approximating the "standard architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR : http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
Quand ESR écrit (dans le chapitre 4) : « Thompson and Ritchie designed C to be a sort of structured assembler », je pense qu'il utilise une antinomie (structuré et assembleur sont bien sûr contradictoires) pour insister sur le fait que le langage C est proche de la machine. Un point sur lequel le C est proche de la machine, par exemple, est la tailles des types entiers. Le type de base char peut faire 8 bits, 9 bits, 24 bits, 32 bits, etc. selon l'implémentation. A contrario, un langage comme Java, qui prend ses distances du matériel grâce à sa machine virtuelle, a des types de tailles fixes (byte : 8 bits, short 16 bits, etc.). Cette proximité avec la machine facilite l'implémentation du langage C et en explique sans doute le succès. Mais ça ne fait pas du C un assembleur. Le langage C est un langage de haut niveau, structuré, déclaratif et récursif, de 3ème génération (3GL), difficilement comparable au langage de 2ème génération qu'est l'assembleur. La brique du langage d'assemblage est l'instruction, or ce concept n'existe pas dans le langage C, qui manipule des objets, des fonctions, des expressions, mais pas d'instructions. Bref, il s'agit de deux langages fondamentalement différents et toutes les boutades qui les comparent sont généralement absurdes.
-- Richard
JKB
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non, ou alors on n'a pas lu la même norme. Il est écrit dans la norme ANSI que c[3][3] déclarait un tableau de 3 lignes et 3 colonnes, que les élements étaient accessibles directement, mais _jamais_ quelle était la structure en mémoire de l'objet.
Cette norme évite la redondance, elle ne répète pas ce qu'elle a déjà dit par ailleurs. En l'occurence, il est spécifié dans le chapitre parlant des tableaux en général qu' un tableau est la juxtaposition (au sens de l'arithmétique des pointeurs) des objets qui le composent. Ça suffit pour lever l'ambiguïté.
Non. Cela ne suffit pas car la norme (ANSI) est assez floue sur ce point particulier (et sur d'autres d'ailleurs). Au passage, la norme n'impose même pas de pouvoir utiliser un pointeur sur le tableau en question. Si vous déclarez c[3][3], la seule façon d'utiliser ce tableau est d'y accéder par c[i][j]. *c peut tout à fait être invalide (si le tableau statique est créé dans la pile au hasard sur processeur Sparc), même si dans la grande majorité des cas, ça passe (et je ne parle pas de **c voire de c[3*i+j], ce dernier type d'accès étant autorisé dans la norme ANSI sur ce type de déclaration de tableau).
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce5bmq.285.bertrand@grossebaf.systella.fr>, a
écrit :
Non, ou alors on n'a pas lu la même norme. Il est écrit dans la
norme ANSI que c[3][3] déclarait un tableau de 3 lignes et 3
colonnes, que les élements étaient accessibles directement, mais
_jamais_ quelle était la structure en mémoire de l'objet.
Cette norme évite la redondance, elle ne répète pas ce qu'elle a déjà
dit par ailleurs. En l'occurence, il est spécifié dans le chapitre
parlant des tableaux en général qu' un tableau est la juxtaposition (au
sens de l'arithmétique des pointeurs) des objets qui le composent. Ça
suffit pour lever l'ambiguïté.
Non. Cela ne suffit pas car la norme (ANSI) est assez floue sur ce
point particulier (et sur d'autres d'ailleurs). Au passage, la norme
n'impose même pas de pouvoir utiliser un pointeur sur le tableau en
question. Si vous déclarez c[3][3], la seule façon d'utiliser ce
tableau est d'y accéder par c[i][j]. *c peut tout à fait être
invalide (si le tableau statique est créé dans la pile au hasard sur
processeur Sparc), même si dans la grande majorité des cas, ça passe
(et je ne parle pas de **c voire de c[3*i+j], ce dernier type d'accès étant
autorisé dans la norme ANSI sur ce type de déclaration de tableau).
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non, ou alors on n'a pas lu la même norme. Il est écrit dans la norme ANSI que c[3][3] déclarait un tableau de 3 lignes et 3 colonnes, que les élements étaient accessibles directement, mais _jamais_ quelle était la structure en mémoire de l'objet.
Cette norme évite la redondance, elle ne répète pas ce qu'elle a déjà dit par ailleurs. En l'occurence, il est spécifié dans le chapitre parlant des tableaux en général qu' un tableau est la juxtaposition (au sens de l'arithmétique des pointeurs) des objets qui le composent. Ça suffit pour lever l'ambiguïté.
Non. Cela ne suffit pas car la norme (ANSI) est assez floue sur ce point particulier (et sur d'autres d'ailleurs). Au passage, la norme n'impose même pas de pouvoir utiliser un pointeur sur le tableau en question. Si vous déclarez c[3][3], la seule façon d'utiliser ce tableau est d'y accéder par c[i][j]. *c peut tout à fait être invalide (si le tableau statique est créé dans la pile au hasard sur processeur Sparc), même si dans la grande majorité des cas, ça passe (et je ne parle pas de **c voire de c[3*i+j], ce dernier type d'accès étant autorisé dans la norme ANSI sur ce type de déclaration de tableau).
JKB
JKB
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
On peut prendre toute autre matière donnant des équations de la même complexité (au hasard la mécanique quantique, l'électromagnétisme, la relativité générale, le traitement du signal... Laquelle préférez-vous ?).
Eh bien j'ai fait quelques calculs sympathique il n'y a pas très longtemps. C'était de la géométrie différentielle avec une métrique de Lorentz, s'il faut tout dire. Évidemment, quand les calculs grossissent trop, j'ai tendance à penser qu'il y a un argument théorique simplificatur qui me manque, et je pars à sa recherche. Ça, ce n'est pas donné aux analystes...
!
Parce que la formalisation infixe apporte une complexité de l'écriture, vous cherchez un argument simplificateur ?
%SYSTEM-F-CONFLICT, Propos conflictuel et ambigu !
JKB
Le 30-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce5bfh.285.bertrand@grossebaf.systella.fr>, a
écrit :
On peut prendre toute autre matière donnant des équations de la même
complexité (au hasard la mécanique quantique, l'électromagnétisme,
la relativité générale, le traitement du signal... Laquelle
préférez-vous ?).
Eh bien j'ai fait quelques calculs sympathique il n'y a pas très
longtemps. C'était de la géométrie différentielle avec une métrique de
Lorentz, s'il faut tout dire. Évidemment, quand les calculs grossissent
trop, j'ai tendance à penser qu'il y a un argument théorique
simplificatur qui me manque, et je pars à sa recherche. Ça, ce n'est pas
donné aux analystes...
!
Parce que la formalisation infixe apporte une complexité de
l'écriture, vous cherchez un argument simplificateur ?
%SYSTEM-F-CONFLICT, Propos conflictuel et ambigu !
Le 30-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
On peut prendre toute autre matière donnant des équations de la même complexité (au hasard la mécanique quantique, l'électromagnétisme, la relativité générale, le traitement du signal... Laquelle préférez-vous ?).
Eh bien j'ai fait quelques calculs sympathique il n'y a pas très longtemps. C'était de la géométrie différentielle avec une métrique de Lorentz, s'il faut tout dire. Évidemment, quand les calculs grossissent trop, j'ai tendance à penser qu'il y a un argument théorique simplificatur qui me manque, et je pars à sa recherche. Ça, ce n'est pas donné aux analystes...
!
Parce que la formalisation infixe apporte une complexité de l'écriture, vous cherchez un argument simplificateur ?
%SYSTEM-F-CONFLICT, Propos conflictuel et ambigu !
JKB
j
Le Wed, 30 Jun 2004 12:01:30 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
Accessoirement, je ne vois pas le rapport avec la choucroute. Monsieur j(c'est son vrai nom ?) évoque des faits qui ne correspondent absolument pas à la réalité de l'enseignement actuel. On est en dro it Les faits correspondent au moins à l'enseignement que j'ai subi au même
titre que mes frères et mes amis ainsi que certains de mes collaborateurs. Je suis trentenaire
Je pense sans me tromper que cet enseignement basé sur le formalisme, la manipulation de concept abstrait et l'apprentissage du «one best way» (la bonne manière de démontrer un problème). La capacité de calcule r ou de faire des calculs complexes est survalorisée au détriment de la capacité d'interprétation est de simplification des problèmes : j'aime beaucoup ce témoignage d'un ancien X
L'Université n'est pas seule en cause. Les équations de Lagrange et le Hamiltonien ne figuraient pas de mon temps au programme de Taupe alors que ce sont les outils essentiels du calcul en physique. L'explication officielle, c'était que si l'on donnait aux taupins des outils puissants ils n'acquerraient pas le sens physique qui suppose (disait-on) l'identification détaillée des forces à l'oeuvre. Je pense plutôt q ue l'on préférait nous priver de ces outils pour nous faire patauger à loisir dans le calcul.
http://www.volle.com/opinion/savoir.htm
Il ne me semble pas que l'enseignement français ait si fondamentalement changé que l'on ne fasse plus la sélection sur le branlage d'équation, et la confusion entre technique scientifique et sciences elles même.
Un bon technicien de l'équation est loin d'être nécessairement un bon scientifique car du haut de sa certitude à pouvoir gérer la complexité il n'aura pas la fainéantise de vouloir trouver un truc simple et efficace et d'imaginer de nouvelles solutions.
de se demander d'où il tire ses renseignements. Je ne met pas mon nom pour pouvoir avoir des arguments basés sur la
logique et non sur les personnes.
Si tu penses que j'ai tort regardons les sujets du bacs et des brevets des collèges pour voir à quels points ils ont évolués au lieu de te nter pathétiquement de faire une diversion sur la personne.
Le Wed, 30 Jun 2004 12:01:30 +0000 (UTC) après l'an de grâce,
inspiré(e) george@clipper.ens.fr (Nicolas George) écrivait la plume
légère :
Accessoirement, je ne vois pas le rapport avec la choucroute. Monsieur
j(c'est son vrai nom ?) évoque des faits qui ne correspondent
absolument pas à la réalité de l'enseignement actuel. On est en dro it
Les faits correspondent au moins à l'enseignement que j'ai subi au même
titre que mes frères et mes amis ainsi que certains de mes
collaborateurs. Je suis trentenaire
Je pense sans me tromper que cet enseignement basé sur le formalisme, la
manipulation de concept abstrait et l'apprentissage du «one best way»
(la bonne manière de démontrer un problème). La capacité de calcule r ou
de faire des calculs complexes est survalorisée au détriment de la
capacité d'interprétation est de simplification des problèmes : j'aime
beaucoup ce témoignage d'un ancien X
L'Université n'est pas seule en cause. Les équations de Lagrange et le
Hamiltonien ne figuraient pas de mon temps au programme de Taupe alors
que ce sont les outils essentiels du calcul en physique. L'explication
officielle, c'était que si l'on donnait aux taupins des outils puissants
ils n'acquerraient pas le sens physique qui suppose (disait-on)
l'identification détaillée des forces à l'oeuvre. Je pense plutôt q ue
l'on préférait nous priver de ces outils pour nous faire patauger à
loisir dans le calcul.
http://www.volle.com/opinion/savoir.htm
Il ne me semble pas que l'enseignement français ait si fondamentalement
changé que l'on ne fasse plus la sélection sur le branlage d'équation,
et la confusion entre technique scientifique et sciences elles même.
Un bon technicien de l'équation est loin d'être nécessairement un bon
scientifique car du haut de sa certitude à pouvoir gérer la complexité
il n'aura pas la fainéantise de vouloir trouver un truc simple et
efficace et d'imaginer de nouvelles solutions.
de se demander d'où il tire ses renseignements.
Je ne met pas mon nom pour pouvoir avoir des arguments basés sur la
logique et non sur les personnes.
Si tu penses que j'ai tort regardons les sujets du bacs et des brevets
des collèges pour voir à quels points ils ont évolués au lieu de te nter
pathétiquement de faire une diversion sur la personne.
Le Wed, 30 Jun 2004 12:01:30 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
Accessoirement, je ne vois pas le rapport avec la choucroute. Monsieur j(c'est son vrai nom ?) évoque des faits qui ne correspondent absolument pas à la réalité de l'enseignement actuel. On est en dro it Les faits correspondent au moins à l'enseignement que j'ai subi au même
titre que mes frères et mes amis ainsi que certains de mes collaborateurs. Je suis trentenaire
Je pense sans me tromper que cet enseignement basé sur le formalisme, la manipulation de concept abstrait et l'apprentissage du «one best way» (la bonne manière de démontrer un problème). La capacité de calcule r ou de faire des calculs complexes est survalorisée au détriment de la capacité d'interprétation est de simplification des problèmes : j'aime beaucoup ce témoignage d'un ancien X
L'Université n'est pas seule en cause. Les équations de Lagrange et le Hamiltonien ne figuraient pas de mon temps au programme de Taupe alors que ce sont les outils essentiels du calcul en physique. L'explication officielle, c'était que si l'on donnait aux taupins des outils puissants ils n'acquerraient pas le sens physique qui suppose (disait-on) l'identification détaillée des forces à l'oeuvre. Je pense plutôt q ue l'on préférait nous priver de ces outils pour nous faire patauger à loisir dans le calcul.
http://www.volle.com/opinion/savoir.htm
Il ne me semble pas que l'enseignement français ait si fondamentalement changé que l'on ne fasse plus la sélection sur le branlage d'équation, et la confusion entre technique scientifique et sciences elles même.
Un bon technicien de l'équation est loin d'être nécessairement un bon scientifique car du haut de sa certitude à pouvoir gérer la complexité il n'aura pas la fainéantise de vouloir trouver un truc simple et efficace et d'imaginer de nouvelles solutions.
de se demander d'où il tire ses renseignements. Je ne met pas mon nom pour pouvoir avoir des arguments basés sur la
logique et non sur les personnes.
Si tu penses que j'ai tort regardons les sujets du bacs et des brevets des collèges pour voir à quels points ils ont évolués au lieu de te nter pathétiquement de faire une diversion sur la personne.
Manuel Leclerc
Jusqu'à l'instruction "indiquée" qui provoque un "undefined".
Comme ça t'a déjà été dit deux fois, « undefined » ne veut dire indéfini que par la norme.
Tu es en train de me dire qu'un ordinateur exécute toujours rigoureusement ce qu'on lui demande d'exécuter. C'est une tautologie qui n'a aucun intérêt dans la discussion en cours. Ni le programmeur, ni le compilateur ne peuvent prévoir ce que _fera_ le programme quand un octet sera écrit là où il ne devrait pas quelque part dans la mémoire du process. En C, c'est d'une facilité déconcertante, notamment à cause des tableaux et de la dualité avec les pointeurs.
Au fond, "undefined", sa vraie signification c'est : "on NE veut PAS que le langage est à prendre en compte ce problème". Comme déjà dit, il faut vivre avec les conséquences.
Jusqu'à l'instruction "indiquée" qui provoque un
"undefined".
Comme ça t'a déjà été dit deux fois, « undefined »
ne veut dire indéfini que par la norme.
Tu es en train de me dire qu'un ordinateur exécute
toujours rigoureusement ce qu'on lui demande d'exécuter.
C'est une tautologie qui n'a aucun intérêt dans la
discussion en cours. Ni le programmeur, ni le compilateur
ne peuvent prévoir ce que _fera_ le programme quand un
octet sera écrit là où il ne devrait pas quelque part
dans la mémoire du process. En C, c'est d'une facilité
déconcertante, notamment à cause des tableaux et de la
dualité avec les pointeurs.
Au fond, "undefined", sa vraie signification c'est :
"on NE veut PAS que le langage est à prendre en compte
ce problème". Comme déjà dit, il faut vivre avec les
conséquences.
Jusqu'à l'instruction "indiquée" qui provoque un "undefined".
Comme ça t'a déjà été dit deux fois, « undefined » ne veut dire indéfini que par la norme.
Tu es en train de me dire qu'un ordinateur exécute toujours rigoureusement ce qu'on lui demande d'exécuter. C'est une tautologie qui n'a aucun intérêt dans la discussion en cours. Ni le programmeur, ni le compilateur ne peuvent prévoir ce que _fera_ le programme quand un octet sera écrit là où il ne devrait pas quelque part dans la mémoire du process. En C, c'est d'une facilité déconcertante, notamment à cause des tableaux et de la dualité avec les pointeurs.
Au fond, "undefined", sa vraie signification c'est : "on NE veut PAS que le langage est à prendre en compte ce problème". Comme déjà dit, il faut vivre avec les conséquences.
george
JKB , dans le message , a écrit :
Parce que la formalisation infixe apporte une complexité de l'écriture, vous cherchez un argument simplificateur ?
Non. L'infixe simplifie les notations, mais pas assez à mon goût. C'était assez minable, comme tentative, je trouve.
JKB , dans le message <slrnce5cvp.285.bertrand@grossebaf.systella.fr>, a
écrit :
Parce que la formalisation infixe apporte une complexité de
l'écriture, vous cherchez un argument simplificateur ?
Non. L'infixe simplifie les notations, mais pas assez à mon goût.
C'était assez minable, comme tentative, je trouve.
