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...
?
3.4.3 1 *undefined behavior* behavior, upon use of a nonportable or erroneous program construct or of erroneous data for which this International Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste dire que le Standard n'en a rien à battre des programmes erronés ou des programmes non portables.
Prends un peu de recul : ce que je critique dans le C, c'est la notion même de programme "erroné". Je ne vois quel point tu fais quand tu cites la norme.
Parce que, à te lire, on pourrait comprendre qu'un comportement indéfini est un comportement aberrant d'un programme, alors qu'il ne s'agit que d'une position d'un comité de normalisation par rapport à la façon de traiter certains programmes erronés, en laissant le choix à l'implémenteur.
Maintenant, si on écrit un programme correct, où est le problème ?
Le comportement indéfini n'est pas un problème quand il ne se produit pas. Sympa comme logique.
Écrire un programme correct en C est faisable. La Norme signale parfaitement toutes les situations produisant un comportement indéfini. On peut les éviter par une bonne connaissance du langage, et la concision du langage C le facilite : il n'y a que 95 comportements indéfinis en C89, soit 4 pages d'erreurs à éviter.
Non, la seule défense du C, c'est que c'est un assembleur portable, et il faut vivre avec les conséquences.
Assimiler le C a de l'assembleur est ridicule.
-- Richard
3.4.3
1 *undefined behavior*
behavior, upon use of a nonportable or erroneous
program construct or of erroneous data for which
this International Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste
dire que le Standard n'en a rien à battre des programmes
erronés ou des programmes non portables.
Prends un peu de recul : ce que je critique dans le C, c'est la
notion même de programme "erroné". Je ne vois quel point tu fais
quand tu cites la norme.
Parce que, à te lire, on pourrait comprendre qu'un comportement indéfini
est un comportement aberrant d'un programme, alors qu'il ne s'agit que
d'une position d'un comité de normalisation par rapport à la façon de
traiter certains programmes erronés, en laissant le choix à l'implémenteur.
Maintenant, si on écrit un programme correct, où est le
problème ?
Le comportement indéfini n'est pas un problème quand il ne
se produit pas. Sympa comme logique.
Écrire un programme correct en C est faisable. La Norme signale
parfaitement toutes les situations produisant un comportement indéfini.
On peut les éviter par une bonne connaissance du langage, et la
concision du langage C le facilite : il n'y a que 95 comportements
indéfinis en C89, soit 4 pages d'erreurs à éviter.
Non, la seule défense du C, c'est que c'est un assembleur
portable, et il faut vivre avec les conséquences.
3.4.3 1 *undefined behavior* behavior, upon use of a nonportable or erroneous program construct or of erroneous data for which this International Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste dire que le Standard n'en a rien à battre des programmes erronés ou des programmes non portables.
Prends un peu de recul : ce que je critique dans le C, c'est la notion même de programme "erroné". Je ne vois quel point tu fais quand tu cites la norme.
Parce que, à te lire, on pourrait comprendre qu'un comportement indéfini est un comportement aberrant d'un programme, alors qu'il ne s'agit que d'une position d'un comité de normalisation par rapport à la façon de traiter certains programmes erronés, en laissant le choix à l'implémenteur.
Maintenant, si on écrit un programme correct, où est le problème ?
Le comportement indéfini n'est pas un problème quand il ne se produit pas. Sympa comme logique.
Écrire un programme correct en C est faisable. La Norme signale parfaitement toutes les situations produisant un comportement indéfini. On peut les éviter par une bonne connaissance du langage, et la concision du langage C le facilite : il n'y a que 95 comportements indéfinis en C89, soit 4 pages d'erreurs à éviter.
Non, la seule défense du C, c'est que c'est un assembleur portable, et il faut vivre avec les conséquences.
Assimiler le C a de l'assembleur est ridicule.
-- Richard
george
JKB , dans le message , a écrit :
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et java avec un JIT ? Et perl ? Et les expressions régulières dans perl ? Et printf en C, c'est compilé ou interprété ?
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un continuum de possibilités, et aucun langage, en partique, ne se situe réellement à un extrême, il y a toujours un peu des deux.
JKB , dans le message <slrnce2s8d.te.bertrand@grossebaf.systella.fr>, a
écrit :
Et pourquoi ? Dans l'ensemble des langages possibles, il existe
l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et
java avec un JIT ? Et perl ? Et les expressions régulières dans perl ?
Et printf en C, c'est compilé ou interprété ?
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un
continuum de possibilités, et aucun langage, en partique, ne se situe
réellement à un extrême, il y a toujours un peu des deux.
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et java avec un JIT ? Et perl ? Et les expressions régulières dans perl ? Et printf en C, c'est compilé ou interprété ?
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un continuum de possibilités, et aucun langage, en partique, ne se situe réellement à un extrême, il y a toujours un peu des deux.
David MAREC
Bonjour, D'après Manuel Leclerc:
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len);
Hum.
strcpy(strdata, library); strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
Les chaines de caractères ont une taille maximum fixe en Pascal, si ma mémoire est bonne. Ce que vous venez d'écrire en Pascal n'est pas l'équivalent de la version "C".
Bonjour,
D'après Manuel Leclerc:
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL)
len = strlen(idstr) + 1;
else
len = strlen(library) + strlen(idstr) + 1;
strdata = (char *) malloc (len);
Hum.
strcpy(strdata, library);
strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
Les chaines de caractères ont une taille maximum fixe en Pascal, si ma
mémoire est bonne.
Ce que vous venez d'écrire en Pascal n'est pas l'équivalent de la
version "C".
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len);
Hum.
strcpy(strdata, library); strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
Les chaines de caractères ont une taille maximum fixe en Pascal, si ma mémoire est bonne. Ce que vous venez d'écrire en Pascal n'est pas l'équivalent de la version "C".
george
"Manuel Leclerc" , dans le message <40e1741a$, a écrit :
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal. ???
Eh bien avec une bonne partie des compilateurs, ce code sera implémenté sous forme de :
Soit path copié trois fois pour rien. Pour éviter ça, il faut que l'optimisation ait été spécifiquement prévue dans le compilateur, et si tu espères que ces optimisations seront prévues dans tous les cas possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java des trucs du style
Soit path copié trois fois pour rien. Pour éviter ça, il faut que
l'optimisation ait été spécifiquement prévue dans le compilateur, et si
tu espères que ces optimisations seront prévues dans tous les cas
possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java
des trucs du style
Soit path copié trois fois pour rien. Pour éviter ça, il faut que l'optimisation ait été spécifiquement prévue dans le compilateur, et si tu espères que ces optimisations seront prévues dans tous les cas possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java des trucs du style
Le 29-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 :
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et java avec un JIT ? Et perl ? Et les expressions régulières dans perl ? Et printf en C, c'est compilé ou interprété ?
Votre question n'a aucun sens. Forth à de rares exceptions est interprété. Printf est géré par le C, donc interprété ou compilé selon l'implantation du langage (il existe des interpréteurs C)...
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un continuum de possibilités, et aucun langage, en partique, ne se situe réellement à un extrême, il y a toujours un peu des deux.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de même que la compilation ne se réduit pas à l'assemblage.
JKB
Le 29-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce2s8d.te.bertrand@grossebaf.systella.fr>, a
écrit :
Et pourquoi ? Dans l'ensemble des langages possibles, il existe
l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et
java avec un JIT ? Et perl ? Et les expressions régulières dans perl ?
Et printf en C, c'est compilé ou interprété ?
Votre question n'a aucun sens. Forth à de rares exceptions est
interprété. Printf est géré par le C, donc interprété ou compilé
selon l'implantation du langage (il existe des interpréteurs C)...
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un
continuum de possibilités, et aucun langage, en partique, ne se situe
réellement à un extrême, il y a toujours un peu des deux.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de
même que la compilation ne se réduit pas à l'assemblage.
Le 29-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 :
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques)
Et dans tout ça, tu places Lisp où ? Forth ? Et java en bytecode ? Et java avec un JIT ? Et perl ? Et les expressions régulières dans perl ? Et printf en C, c'est compilé ou interprété ?
Votre question n'a aucun sens. Forth à de rares exceptions est interprété. Printf est géré par le C, donc interprété ou compilé selon l'implantation du langage (il existe des interpréteurs C)...
Entre l'assembleur pur et l'interprété pas à pas, il y a tout un continuum de possibilités, et aucun langage, en partique, ne se situe réellement à un extrême, il y a toujours un peu des deux.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de même que la compilation ne se réduit pas à l'assemblage.
JKB
j
Le Tue, 29 Jun 2004 13:25:38 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce formalisme qui est employé. Cependant, cette notation a de gros problèmes pour l'enseignement, en ce qu'elle favorise manipulations qui ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simpl ifier f
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la géométrie comme manière d'apprendre les maths et remplacer cela par l'apprentissage des théories ensemblistes : raison officielle :
dans f'/f, et ne garder que ', si on enseignait la même chose avec les formes différentielles, 80% des élèves, au bas mot, feraient n'impo rte quoi. Le pire étant qu'environ la moitié des manipulations abusives
Quand les élèves dessinent ils font toujours des figures particulières qu'ils prennent pour le cas général.
Cependant tant la géométrie que la notation de Leibniz aussi fausses soient-elles permettent se bâtir une intuition des maths
Quant aux smplification si on regarde les domaines où elles sont valides (aka les fonctions de physiciens ie. celles qui sont dérivables à l'infini, continues en tout point ou presque ;) ), elles sont tout à fait légitimes. Oui, la plupart du temps df(x,y)/dxdyß(x,y)/dydx et quand c'est plus le cas, c'est que vous êtes un chercheur qui travaille sur un problème pointu.
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
qu'on a envie de faire avec les dx sont, au final, exactes, mais pour des raisons autres.
Tu es contre le RPN qui est plus simple (car moins trompeur que les parenthèses) mais contre-intuitif, et et tu es pour la notation de Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ? En fait, tu es pour faire ce qui a été toujours fait ?
Soit dit en passant, le professeur Gleick (épistémologue) écorne la raison officielle de l'utilisation de la théorie des ensembles pour l'apprentissage. Selon lui, l'école mathématique française bien représentée à normale aurait été un peu énervée par Poincar é (le dernier grand mathématicien français) qui se serait mis en avant et surtout prétendait que l'intuitation et la créativité sont bien plus fondamentales en sciences que le formalisme et la technique.
La sélection par les maths moderne ne mesure pas le niveau scientifique d'un étudiant, mais juste sa capacité à être un singe savant.
-- Progress might have been all right once, but it's gone on too long. -- Ogden Nash
Le Tue, 29 Jun 2004 13:25:38 +0000 (UTC) après l'an de grâce,
inspiré(e) george@clipper.ens.fr (Nicolas George) écrivait la plume
légère :
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce
formalisme qui est employé. Cependant, cette notation a de gros
problèmes pour l'enseignement, en ce qu'elle favorise manipulations
qui ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simpl ifier
f
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la
géométrie comme manière d'apprendre les maths et remplacer cela par
l'apprentissage des théories ensemblistes :
raison officielle :
dans f'/f, et ne garder que ', si on enseignait la même chose avec les
formes différentielles, 80% des élèves, au bas mot, feraient n'impo rte
quoi. Le pire étant qu'environ la moitié des manipulations abusives
Quand les élèves dessinent ils font toujours des figures particulières
qu'ils prennent pour le cas général.
Cependant tant la géométrie que la notation de Leibniz aussi fausses
soient-elles permettent se bâtir une intuition des maths
Quant aux smplification si on regarde les domaines où elles sont
valides (aka les fonctions de physiciens ie. celles qui sont dérivables
à l'infini, continues en tout point ou presque ;) ), elles sont tout à
fait légitimes.
Oui, la plupart du temps df(x,y)/dxdy=df(x,y)/dydx et quand c'est plus
le cas, c'est que vous êtes un chercheur qui travaille sur un problème
pointu.
En math ce qui doit primer c'est la capacité à manipuler les outils pour
obtenir un résultat où la capacité à montrer que l'on est capable de
manipuler le formalisme?
qu'on a envie de faire avec les dx sont, au final, exactes, mais pour
des raisons autres.
Tu es contre le RPN qui est plus simple (car moins trompeur que les
parenthèses) mais contre-intuitif, et et tu es pour la notation de
Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ?
En fait, tu es pour faire ce qui a été toujours fait ?
Soit dit en passant, le professeur Gleick (épistémologue) écorne la
raison officielle de l'utilisation de la théorie des ensembles pour
l'apprentissage. Selon lui, l'école mathématique française bien
représentée à normale aurait été un peu énervée par Poincar é (le dernier
grand mathématicien français) qui se serait mis en avant et surtout
prétendait que l'intuitation et la créativité sont bien plus
fondamentales en sciences que le formalisme et la technique.
La sélection par les maths moderne ne mesure pas le niveau scientifique
d'un étudiant, mais juste sa capacité à être un singe savant.
--
Progress might have been all right once, but it's gone on too long.
-- Ogden Nash
Le Tue, 29 Jun 2004 13:25:38 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce formalisme qui est employé. Cependant, cette notation a de gros problèmes pour l'enseignement, en ce qu'elle favorise manipulations qui ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simpl ifier f
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la géométrie comme manière d'apprendre les maths et remplacer cela par l'apprentissage des théories ensemblistes : raison officielle :
dans f'/f, et ne garder que ', si on enseignait la même chose avec les formes différentielles, 80% des élèves, au bas mot, feraient n'impo rte quoi. Le pire étant qu'environ la moitié des manipulations abusives
Quand les élèves dessinent ils font toujours des figures particulières qu'ils prennent pour le cas général.
Cependant tant la géométrie que la notation de Leibniz aussi fausses soient-elles permettent se bâtir une intuition des maths
Quant aux smplification si on regarde les domaines où elles sont valides (aka les fonctions de physiciens ie. celles qui sont dérivables à l'infini, continues en tout point ou presque ;) ), elles sont tout à fait légitimes. Oui, la plupart du temps df(x,y)/dxdyß(x,y)/dydx et quand c'est plus le cas, c'est que vous êtes un chercheur qui travaille sur un problème pointu.
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
qu'on a envie de faire avec les dx sont, au final, exactes, mais pour des raisons autres.
Tu es contre le RPN qui est plus simple (car moins trompeur que les parenthèses) mais contre-intuitif, et et tu es pour la notation de Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ? En fait, tu es pour faire ce qui a été toujours fait ?
Soit dit en passant, le professeur Gleick (épistémologue) écorne la raison officielle de l'utilisation de la théorie des ensembles pour l'apprentissage. Selon lui, l'école mathématique française bien représentée à normale aurait été un peu énervée par Poincar é (le dernier grand mathématicien français) qui se serait mis en avant et surtout prétendait que l'intuitation et la créativité sont bien plus fondamentales en sciences que le formalisme et la technique.
La sélection par les maths moderne ne mesure pas le niveau scientifique d'un étudiant, mais juste sa capacité à être un singe savant.
-- Progress might have been all right once, but it's gone on too long. -- Ogden Nash
remy
"Nicolas George" a écrit dans le message de news: cbrtg8$hnb$
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal. ???
Eh bien avec une bonne partie des compilateurs, ce code sera implémenté sous forme de :
Soit path copié trois fois pour rien. Pour éviter ça, il faut que l'optimisation ait été spécifiquement prévue dans le compilateur, et si tu espères que ces optimisations seront prévues dans tous les cas possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java des trucs du style
Soit path copié trois fois pour rien. Pour éviter ça, il faut que
l'optimisation ait été spécifiquement prévue dans le compilateur, et si
tu espères que ces optimisations seront prévues dans tous les cas
possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java
des trucs du style
Soit path copié trois fois pour rien. Pour éviter ça, il faut que l'optimisation ait été spécifiquement prévue dans le compilateur, et si tu espères que ces optimisations seront prévues dans tous les cas possibles, tu es bien naïf.
Et ceci est un problème bien réel. J'ai déjà vu des gens coder en java des trucs du style
tu propose quoi comme autre solution en java a+ remy
Je ne te racconte pas la lenteur du résultat.
Richard Delorme
Si, par « mécanisme "built-in" », tu veux dire que les autres langages font des choses, comme l'allocation dynamique ou la mesure de la longueur d'une chaîne, sans qu'on leur demande, alors qu'en C tout est explicite, c'est pour moi indiscutable que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len); strcpy(strdata, library); strcat(strdata, idstr);
Ça commence bien : comportement indéfini si strdata ou library vaut NULL, utilisation d'un idenficateur réservé (strdata), cast inutile, ...
Une version plus correcte et plus rapide serait :
/* library & idstr sont supposées être des chaines valides */ l_library = strlen(library); l_idstr = strlen(idstr); sdata = malloc(l_idstr + l_library + 1); if (sdata) { strcpy(sdata, library); strcpy(sdata + l_library, idstr); }
En pascal, c'est plutôt :
strdata := library + idstr;
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
L version C sera un plus performante au niveau mémoire et CPU ? Ce n'est pas évident. strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Si, mais il faut les utiliser à bon escient.
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
-- Richard
Si, par « mécanisme "built-in" », tu veux dire que les autres
langages font des choses, comme l'allocation dynamique ou la
mesure de la longueur d'une chaîne, sans qu'on leur demande,
alors qu'en C tout est explicite, c'est pour moi indiscutable
que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL)
len = strlen(idstr) + 1;
else
len = strlen(library) + strlen(idstr) + 1;
strdata = (char *) malloc (len);
strcpy(strdata, library);
strcat(strdata, idstr);
Ça commence bien : comportement indéfini si strdata ou library vaut
NULL, utilisation d'un idenficateur réservé (strdata), cast inutile, ...
Une version plus correcte et plus rapide serait :
/* library & idstr sont supposées être des chaines valides */
l_library = strlen(library);
l_idstr = strlen(idstr);
sdata = malloc(l_idstr + l_library + 1);
if (sdata) {
strcpy(sdata, library);
strcpy(sdata + l_library, idstr);
}
En pascal, c'est plutôt :
strdata := library + idstr;
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour
strdata ? Il n'a pas besoin de connaître la longueur de library pour lui
concaténer idstr ?
La différence c'est que le comportement ici est opaque, tandis qu'en C,
il est explicite.
L version C sera un plus performante au niveau mémoire
et CPU ? Ce n'est pas évident. strlen et strcat ne
sont pas des fonctions particulièrement conçues pour
optimiser les performances de manipulations de chaîne,
me semble-t-il...
Si, mais il faut les utiliser à bon escient.
En tout cas, au jour d'aujourd'hui, pour des vrais
programmes de la vraie vie, je classe la version C dans
la catégorie "brain fuck".
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
Si, par « mécanisme "built-in" », tu veux dire que les autres langages font des choses, comme l'allocation dynamique ou la mesure de la longueur d'une chaîne, sans qu'on leur demande, alors qu'en C tout est explicite, c'est pour moi indiscutable que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len); strcpy(strdata, library); strcat(strdata, idstr);
Ça commence bien : comportement indéfini si strdata ou library vaut NULL, utilisation d'un idenficateur réservé (strdata), cast inutile, ...
Une version plus correcte et plus rapide serait :
/* library & idstr sont supposées être des chaines valides */ l_library = strlen(library); l_idstr = strlen(idstr); sdata = malloc(l_idstr + l_library + 1); if (sdata) { strcpy(sdata, library); strcpy(sdata + l_library, idstr); }
En pascal, c'est plutôt :
strdata := library + idstr;
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
L version C sera un plus performante au niveau mémoire et CPU ? Ce n'est pas évident. strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Si, mais il faut les utiliser à bon escient.
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
-- Richard
chmod 777
Manuel Leclerc wrote:
C'est un truc genre "type de donnée string" par exemple. Comme en pascal.
Pascal est un type en string?
OK, OK, pas taper!!!
Je n'ai pas pu résister: j'ai dû trop fréquenter alt.sex.nimporte.quoi ;o)
Lionel
-- Mon adresse EST valide: ne rien supprimer! J'espère être tranquille grâce à la méthode Paugam
Manuel Leclerc wrote:
C'est un truc genre "type de donnée string" par exemple. Comme
en pascal.
Pascal est un type en string?
OK, OK, pas taper!!!
Je n'ai pas pu résister: j'ai dû trop fréquenter alt.sex.nimporte.quoi ;o)
Lionel
--
Mon adresse EST valide: ne rien supprimer!
J'espère être tranquille grâce à la méthode Paugam
C'est un truc genre "type de donnée string" par exemple. Comme en pascal.
Pascal est un type en string?
OK, OK, pas taper!!!
Je n'ai pas pu résister: j'ai dû trop fréquenter alt.sex.nimporte.quoi ;o)
Lionel
-- Mon adresse EST valide: ne rien supprimer! J'espère être tranquille grâce à la méthode Paugam
remy
Une version plus correcte et plus rapide serait :
/* library & idstr sont supposées être des chaines valides */ l_library = strlen(library); l_idstr = strlen(idstr); sdata = malloc(l_idstr + l_library + 1); if (sdata) { strcpy(sdata, library); strcpy(sdata + l_library, idstr); }
prenons un cas "classique"
une base de donnees avec une tab tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener et tu dois enrober chaque ligne du tableau de quelques balises html par exemple
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui qui a un cout de maintenance le moins cher et au niveau rapidite d'execution l'on est pas loin du kif kif avec du c propre sans parler de l'interaction avec la base de donnees
donc le langage depend de l'objectif a mon avi
a+ remy
Une version plus correcte et plus rapide serait :
/* library & idstr sont supposées être des chaines valides */
l_library = strlen(library);
l_idstr = strlen(idstr);
sdata = malloc(l_idstr + l_library + 1);
if (sdata) {
strcpy(sdata, library);
strcpy(sdata + l_library, idstr);
}
prenons un cas "classique"
une base de donnees avec une tab
tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener
et tu dois enrober chaque ligne du tableau de quelques balises html
par exemple
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui
qui a un cout de maintenance le moins cher
et au niveau rapidite d'execution l'on est pas loin du kif kif
avec du c propre
sans parler de l'interaction avec la base de donnees
/* library & idstr sont supposées être des chaines valides */ l_library = strlen(library); l_idstr = strlen(idstr); sdata = malloc(l_idstr + l_library + 1); if (sdata) { strcpy(sdata, library); strcpy(sdata + l_library, idstr); }
prenons un cas "classique"
une base de donnees avec une tab tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener et tu dois enrober chaque ligne du tableau de quelques balises html par exemple
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui qui a un cout de maintenance le moins cher et au niveau rapidite d'execution l'on est pas loin du kif kif avec du c propre sans parler de l'interaction avec la base de donnees
