J'ai écrit une fonction qui remplace la virgule par un point dans une chaine de caractères pour ensuite permettre de faire un
calcul.
Pour copier une chaine dans une autre chaine, j'utilise memcpy.
Est ce nécessaire d'écrire
memcpy(ch, c, sizeof(char) * taille);
ou bien je peux me contenter d'écrire
memcpy(ch, c, taille);
Toutes critiques sur la fonction seront les bienvenues.
Merci.
Alain CROS
#include <string.h>
int convstrnum(int taille, char *c)
/* Remplace, dans une chaine de caractères représentant un chiffre,
la virgule par un point.
Retourne :
la position de ce point dans la chaine (base 1).
0 si pas de point.
-1 si pas un chiffre (la chaine reste inchangée).
*/
{
int i = 1, j = 0, k = 0;
char ch[taille + 1];
char *pch = ch;
memcpy(ch, c, sizeof(char) * taille);
ch[taille] = '\0';
while(*pch != '\0')
{
if((*pch < '0') || (*pch > '9'))
switch(*pch)
{
case '.':
j = (++k == 2) ? -1 : j;
break;
case ',':
*pch-- = '.';
j = i--;
break;
default:
j = -1;
}
if(j == -1)
break;
*pch++;
i++;
}
if(j != -1)
memcpy(c, ch, sizeof(char) * taille);
return(j);
}
Il suffit d'utiliser un index basé en 0 comme il se doit et c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1 méritent le bûcher, nous ne saurions admettre cette hérésie et elle doit être combattue toutes affaires cessantes. Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
-- Chqrlie.
"Harpo" <trashcan@hotmail.com> wrote in message
news:43371c8c$0$17210$8fcfb975@news.wanadoo.fr...
Emmanuel Delahaye wrote:
Il suffit d'utiliser un index basé en 0 comme il se doit et
c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1
méritent le bûcher, nous ne saurions admettre cette hérésie et elle
doit être combattue toutes affaires cessantes.
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison
d'avoir choisi cette interface et, si elle n'est pas la meilleure
possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Il suffit d'utiliser un index basé en 0 comme il se doit et c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1 méritent le bûcher, nous ne saurions admettre cette hérésie et elle doit être combattue toutes affaires cessantes. Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
-- Chqrlie.
Charlie Gordon
"Harpo" wrote in message news:433735bd$0$1717$
Alain CROS wrote:
int convstrnum(int taille, char *c)
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables, personnellement trouver le nom des variables et autres identifieurs me prend environ 50% du temps de l'écriture du code, et encore c'est quand c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps soit excessif, je ne pense pas qu'il soit perdu.
Il est important effectivement de nommer les variables correctement. i est un nom correct pour l'indice d'une boucle simple loopIndex est un nom débile pour cette variable.
Tu écris des trucs comme : if ( blqh ) blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test avec des espaces, ou pire encore les point-virgule de fin d'instruction... quel style horrible.
il est très rare que cela se justifie écris plutôt : if ( blqh ) { blurb ; }
non, c'est sans doute moins risqué, mais ce n'est pas plus lisible.
Si tu ne comprends pas pourquoi, un jour tu comprendras. Où alors : if ( blqh ) { blurb ; }
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs :-) C'est d'ailleurs le style de K&R pour les blocs non triviaux
Je crois d'ailleurs que je vais revenir à ce style.
faites ce que je dis, je m'y mets bientôt ;-)
Le style d'écriture est très important, cela donne une cohérence. J'essaye de me conformer à peu près aux standards ci-dessous. http://www.gnu.org/prep/standards/standards.html sauf lorsque je considère que mon idée est meilleure et que j'ai de bonnes raisons de penser qu'elle l'est,
Justement, les conventions GNU sont encore différentes en ce qui concerne l'exemple que tu donnes. Leur convention pour le positionnement des accolades est horrible.
le principal est qu'un même style soit utilisé dans un projet, au minimum dans un fichier source.
indéniablement !
-- Chqrlie.
"Harpo" <trashcan@hotmail.com> wrote in message
news:433735bd$0$1717$8fcfb975@news.wanadoo.fr...
Alain CROS wrote:
int convstrnum(int taille, char *c)
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu
en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables,
personnellement trouver le nom des variables et autres identifieurs me
prend environ 50% du temps de l'écriture du code, et encore c'est quand
c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps
soit excessif, je ne pense pas qu'il soit perdu.
Il est important effectivement de nommer les variables correctement.
i est un nom correct pour l'indice d'une boucle simple
loopIndex est un nom débile pour cette variable.
Tu écris des trucs comme :
if ( blqh )
blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test avec des
espaces, ou pire encore les point-virgule de fin d'instruction... quel style
horrible.
il est très rare que cela se justifie
écris plutôt :
if ( blqh )
{
blurb ;
}
non, c'est sans doute moins risqué, mais ce n'est pas plus lisible.
Si tu ne comprends pas pourquoi, un jour tu comprendras.
Où alors :
if ( blqh ) {
blurb ;
}
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs :-)
C'est d'ailleurs le style de K&R pour les blocs non triviaux
Je crois d'ailleurs que je vais revenir à ce style.
faites ce que je dis, je m'y mets bientôt ;-)
Le style d'écriture est très important, cela donne une cohérence.
J'essaye de me conformer à peu près aux standards ci-dessous.
http://www.gnu.org/prep/standards/standards.html
sauf lorsque je considère que mon idée est meilleure et que j'ai de
bonnes raisons de penser qu'elle l'est,
Justement, les conventions GNU sont encore différentes en ce qui concerne
l'exemple que tu donnes.
Leur convention pour le positionnement des accolades est horrible.
le principal est qu'un même
style soit utilisé dans un projet, au minimum dans un fichier source.
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables, personnellement trouver le nom des variables et autres identifieurs me prend environ 50% du temps de l'écriture du code, et encore c'est quand c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps soit excessif, je ne pense pas qu'il soit perdu.
Il est important effectivement de nommer les variables correctement. i est un nom correct pour l'indice d'une boucle simple loopIndex est un nom débile pour cette variable.
Tu écris des trucs comme : if ( blqh ) blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test avec des espaces, ou pire encore les point-virgule de fin d'instruction... quel style horrible.
il est très rare que cela se justifie écris plutôt : if ( blqh ) { blurb ; }
non, c'est sans doute moins risqué, mais ce n'est pas plus lisible.
Si tu ne comprends pas pourquoi, un jour tu comprendras. Où alors : if ( blqh ) { blurb ; }
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs :-) C'est d'ailleurs le style de K&R pour les blocs non triviaux
Je crois d'ailleurs que je vais revenir à ce style.
faites ce que je dis, je m'y mets bientôt ;-)
Le style d'écriture est très important, cela donne une cohérence. J'essaye de me conformer à peu près aux standards ci-dessous. http://www.gnu.org/prep/standards/standards.html sauf lorsque je considère que mon idée est meilleure et que j'ai de bonnes raisons de penser qu'elle l'est,
Justement, les conventions GNU sont encore différentes en ce qui concerne l'exemple que tu donnes. Leur convention pour le positionnement des accolades est horrible.
le principal est qu'un même style soit utilisé dans un projet, au minimum dans un fichier source.
indéniablement !
-- Chqrlie.
Charlie Gordon
"Harpo" wrote in message news:43373889$0$27405$
Charlie Gordon wrote:
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir modifié la chaîne, O ne peut pas désigner l'offset de la virgule transformée en point. Il n'est pas spécifié qu'un nombre ne peut commencer par une virgule. La valeur de retour 0 serait ambigue. Bien que cela soit d'une élégance douteuse, passer la position à la place de l'offset se justifie.
Je cite Alain CROS:
/* Remplace, dans une chaine de caractères représentant un chiffre, la virgule par un point. Retourne : la position de ce point dans la chaine (base 1). 0 si pas de point. -1 si pas un chiffre (la chaine reste inchangée). */
0 veut simplement dire "pas de point" et implicitement, chaine correcte. La documentation d'Alain mentionne cela en second, on peut donc supposer que l'objectif principal de cette fonction est de retourner la position du point. Dès lors, les 2 autres résultats possibles doivent effectivement être cohérents avec la séantique principale. Tordre la sémantique principale en prenant la base 1 et en appelant cela abusivement "position" est une mauvaise solution, peut-être le fruit d'une expérience dans d'autres langages.
-- Chqrlie.
"Harpo" <trashcan@hotmail.com> wrote in message
news:43373889$0$27405$8fcfb975@news.wanadoo.fr...
Charlie Gordon wrote:
Cependant, et pour me faire l'avocat du diable, Alain a une bonne
raison d'avoir choisi cette interface et, si elle n'est pas la
meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir
modifié la chaîne, O ne peut pas désigner l'offset de la virgule
transformée en point. Il n'est pas spécifié qu'un nombre ne peut
commencer par une virgule.
La valeur de retour 0 serait ambigue.
Bien que cela soit d'une élégance douteuse, passer la position à la
place de l'offset se justifie.
Je cite Alain CROS:
/* Remplace, dans une chaine de caractères représentant un chiffre,
la virgule par un point.
Retourne :
la position de ce point dans la chaine (base 1).
0 si pas de point.
-1 si pas un chiffre (la chaine reste inchangée).
*/
0 veut simplement dire "pas de point" et implicitement, chaine correcte.
La documentation d'Alain mentionne cela en second, on peut donc supposer que
l'objectif principal de cette fonction est de retourner la position du point.
Dès lors, les 2 autres résultats possibles doivent effectivement être cohérents
avec la séantique principale. Tordre la sémantique principale en prenant la
base 1 et en appelant cela abusivement "position" est une mauvaise solution,
peut-être le fruit d'une expérience dans d'autres langages.
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir modifié la chaîne, O ne peut pas désigner l'offset de la virgule transformée en point. Il n'est pas spécifié qu'un nombre ne peut commencer par une virgule. La valeur de retour 0 serait ambigue. Bien que cela soit d'une élégance douteuse, passer la position à la place de l'offset se justifie.
Je cite Alain CROS:
/* Remplace, dans une chaine de caractères représentant un chiffre, la virgule par un point. Retourne : la position de ce point dans la chaine (base 1). 0 si pas de point. -1 si pas un chiffre (la chaine reste inchangée). */
0 veut simplement dire "pas de point" et implicitement, chaine correcte. La documentation d'Alain mentionne cela en second, on peut donc supposer que l'objectif principal de cette fonction est de retourner la position du point. Dès lors, les 2 autres résultats possibles doivent effectivement être cohérents avec la séantique principale. Tordre la sémantique principale en prenant la base 1 et en appelant cela abusivement "position" est une mauvaise solution, peut-être le fruit d'une expérience dans d'autres langages.
-- Chqrlie.
Charlie Gordon
"Harpo" wrote in message news:43373889$0$27405$
Ton fuseau horaire est mal réglé, cela trouble les serveurs de news et certains de leurs clients ;-)
<43371c8c$0$17210$ <dh79us$skj$ Organization: ARG ; Association pour la Rehabilitation du Goto User-Agent: KNode/0.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8Bit Lines: 15 NNTP-Posting-Date: 26 Sep 2005 01:53:45 CEST NNTP-Posting-Host: 83.195.26.119 X-Trace: 1127692425 news.wanadoo.fr 27405 83.195.26.119:32842 X-Complaints-To: Xref: writer fr.comp.lang.c:86708
Harpo
Emmanuel Delahaye wrote:
Pourquoi est-ce aussi compliqué avec des +1 et des -1 dans tous les sens.
Ou vois-tu des +1 et des -1 dans tous les sens ?
Il suffit d'utiliser un index basé en 0 comme il se doit et c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1 méritent le bûcher, nous ne saurions admettre cette hérésie et elle doit être combattue toutes affaires cessantes. Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Emmanuel Delahaye wrote:
Pourquoi est-ce aussi compliqué avec des +1 et des -1 dans tous les
sens.
Ou vois-tu des +1 et des -1 dans tous les sens ?
Il suffit d'utiliser un index basé en 0 comme il se doit et
c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1
méritent le bûcher, nous ne saurions admettre cette hérésie et elle
doit être combattue toutes affaires cessantes.
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison
d'avoir choisi cette interface et, si elle n'est pas la meilleure
possible, elle est au moins raisonnée.
Pourquoi est-ce aussi compliqué avec des +1 et des -1 dans tous les sens.
Ou vois-tu des +1 et des -1 dans tous les sens ?
Il suffit d'utiliser un index basé en 0 comme il se doit et c'est tout.
Bien sûr, moi aussi je pense que les gens qui comptent à partir de 1 méritent le bûcher, nous ne saurions admettre cette hérésie et elle doit être combattue toutes affaires cessantes. Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Harpo
Alain CROS wrote:
int convstrnum(int taille, char *c)
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables, personnellement trouver le nom des variables et autres identifieurs me prend environ 50% du temps de l'écriture du code, et encore c'est quand c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps soit excessif, je ne pense pas qu'il soit perdu.
Tu écris des trucs comme : if ( blqh ) blurb ;
il est très rare que cela se justifie écris plutôt : if ( blqh ) { blurb ; }
Si tu ne comprends pas pourquoi, un jour tu comprendras. Où alors : if ( blqh ) { blurb ; }
Je crois d'ailleurs que je vais revenir à ce style.
Le style d'écriture est très important, cela donne une cohérence. J'essaye de me conformer à peu près aux standards ci-dessous. http://www.gnu.org/prep/standards/standards.html sauf lorsque je considère que mon idée est meilleure et que j'ai de bonnes raisons de penser qu'elle l'est, le principal est qu'un même style soit utilisé dans un projet, au minimum dans un fichier source.
Alain CROS wrote:
int convstrnum(int taille, char *c)
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu
en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables,
personnellement trouver le nom des variables et autres identifieurs me
prend environ 50% du temps de l'écriture du code, et encore c'est quand
c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps
soit excessif, je ne pense pas qu'il soit perdu.
Tu écris des trucs comme :
if ( blqh )
blurb ;
il est très rare que cela se justifie
écris plutôt :
if ( blqh )
{
blurb ;
}
Si tu ne comprends pas pourquoi, un jour tu comprendras.
Où alors :
if ( blqh ) {
blurb ;
}
Je crois d'ailleurs que je vais revenir à ce style.
Le style d'écriture est très important, cela donne une cohérence.
J'essaye de me conformer à peu près aux standards ci-dessous.
http://www.gnu.org/prep/standards/standards.html
sauf lorsque je considère que mon idée est meilleure et que j'ai de
bonnes raisons de penser qu'elle l'est, le principal est qu'un même
style soit utilisé dans un projet, au minimum dans un fichier source.
Il y a comme qui dirait un sérieux progrès, mais je l'ai simplement lu en diagonale.
2 ou 3 trucs :
Essaye de donner des noms encore plus parlant à tes variables, personnellement trouver le nom des variables et autres identifieurs me prend environ 50% du temps de l'écriture du code, et encore c'est quand c'est un jour où j'ai de l'imagination. Bien que je pense que ce temps soit excessif, je ne pense pas qu'il soit perdu.
Tu écris des trucs comme : if ( blqh ) blurb ;
il est très rare que cela se justifie écris plutôt : if ( blqh ) { blurb ; }
Si tu ne comprends pas pourquoi, un jour tu comprendras. Où alors : if ( blqh ) { blurb ; }
Je crois d'ailleurs que je vais revenir à ce style.
Le style d'écriture est très important, cela donne une cohérence. J'essaye de me conformer à peu près aux standards ci-dessous. http://www.gnu.org/prep/standards/standards.html sauf lorsque je considère que mon idée est meilleure et que j'ai de bonnes raisons de penser qu'elle l'est, le principal est qu'un même style soit utilisé dans un projet, au minimum dans un fichier source.
Harpo
Charlie Gordon wrote:
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir modifié la chaîne, O ne peut pas désigner l'offset de la virgule transformée en point. Il n'est pas spécifié qu'un nombre ne peut commencer par une virgule. La valeur de retour 0 serait ambigue. Bien que cela soit d'une élégance douteuse, passer la position à la place de l'offset se justifie.
Charlie Gordon wrote:
Cependant, et pour me faire l'avocat du diable, Alain a une bonne
raison d'avoir choisi cette interface et, si elle n'est pas la
meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir
modifié la chaîne, O ne peut pas désigner l'offset de la virgule
transformée en point. Il n'est pas spécifié qu'un nombre ne peut
commencer par une virgule.
La valeur de retour 0 serait ambigue.
Bien que cela soit d'une élégance douteuse, passer la position à la
place de l'offset se justifie.
Cependant, et pour me faire l'avocat du diable, Alain a une bonne raison d'avoir choisi cette interface et, si elle n'est pas la meilleure possible, elle est au moins raisonnée.
Quelle est-donc cette bonne raison qui nous échappe ?
Si 0 doit indiquer que la fonction s'est bien déroulée sans avoir modifié la chaîne, O ne peut pas désigner l'offset de la virgule transformée en point. Il n'est pas spécifié qu'un nombre ne peut commencer par une virgule. La valeur de retour 0 serait ambigue. Bien que cela soit d'une élégance douteuse, passer la position à la place de l'offset se justifie.
Pierre Habouzit
Charlie Gordon wrote:
Justement, les conventions GNU sont encore différentes en ce qui concerne l'exemple que tu donnes. Leur convention pour le positionnement des accolades est horrible.
comment ? tu n'aimes pas :
if (blah) { gerbons_ensemble(); }
(ok, je connais la sortie) -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Charlie Gordon wrote:
Justement, les conventions GNU sont encore différentes en ce qui concerne
l'exemple que tu donnes.
Leur convention pour le positionnement des accolades est horrible.
comment ? tu n'aimes pas :
if (blah)
{
gerbons_ensemble();
}
(ok, je connais la sortie)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Justement, les conventions GNU sont encore différentes en ce qui concerne l'exemple que tu donnes. Leur convention pour le positionnement des accolades est horrible.
comment ? tu n'aimes pas :
if (blah) { gerbons_ensemble(); }
(ok, je connais la sortie) -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Pierre Habouzit
Faudra regarder si leurs pretentions en termes d'optimisations sont justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas super fort en optimisations, surtout au niveau du code generé pour des architectures particulieres, alors qu'on peut imaginer qu'un compilateur produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par CPU montrent que pour des applis particulières (typiquement calculatoires) icc fait du meilleur travail, et avec des résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1 (encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est complètement obsolète et réservé à des vieux barbus (j'ai rien contreles vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Faudra regarder si leurs pretentions en termes d'optimisations sont
justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas
super fort en optimisations, surtout au niveau du code generé pour des
architectures particulieres, alors qu'on peut imaginer qu'un compilateur
produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par
CPU montrent que pour des applis particulières (typiquement calculatoires)
icc fait du meilleur travail, et avec des résultats sensiblement meilleurs
(un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un
traitement de texte et autres applis avec des cycles de calculs courts dans
le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1
(encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à
vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est
complètement obsolète et réservé à des vieux barbus (j'ai rien contreles
vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt
sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code
pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private>
Et puis de toute facon, plus personne ne fait du C, ni même de C++
aujourd'hui. Quelle idée, maintenant il y a Java !!!
</private
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Faudra regarder si leurs pretentions en termes d'optimisations sont justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas super fort en optimisations, surtout au niveau du code generé pour des architectures particulieres, alors qu'on peut imaginer qu'un compilateur produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par CPU montrent que pour des applis particulières (typiquement calculatoires) icc fait du meilleur travail, et avec des résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1 (encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est complètement obsolète et réservé à des vieux barbus (j'ai rien contreles vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Pierre Habouzit
Faudra regarder si leurs pretentions en termes d'optimisations sont justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas super fort en optimisations, surtout au niveau du code generé pour des architectures particulieres, alors qu'on peut imaginer qu'un compilateur produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par CPU montrent que pour des applis particulières (typiquement calculatoires) icc fait du meilleur travail, et avec des résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1 (encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est complètement obsolète et réservé à des vieux barbus (j'ai rien contreles vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private>
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Faudra regarder si leurs pretentions en termes d'optimisations sont
justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas
super fort en optimisations, surtout au niveau du code generé pour des
architectures particulieres, alors qu'on peut imaginer qu'un compilateur
produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par
CPU montrent que pour des applis particulières (typiquement calculatoires)
icc fait du meilleur travail, et avec des résultats sensiblement meilleurs
(un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un
traitement de texte et autres applis avec des cycles de calculs courts dans
le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1
(encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à
vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est
complètement obsolète et réservé à des vieux barbus (j'ai rien contreles
vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt
sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code
pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private>
Et puis de toute facon, plus personne ne fait du C, ni même de C++
aujourd'hui. Quelle idée, maintenant il y a Java !!!
</private>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Faudra regarder si leurs pretentions en termes d'optimisations sont justifiees. Ils citent essentiellement gcc comme reference, qui n'est pas super fort en optimisations, surtout au niveau du code generé pour des architectures particulieres, alors qu'on peut imaginer qu'un compilateur produit par intel n'a que cela comme objectif.
à priori, les gentoo-istes et autres accros du réchauffement climatique par CPU montrent que pour des applis particulières (typiquement calculatoires) icc fait du meilleur travail, et avec des résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Quant à ce qui est de gcc, pas mal de monde s'accorde à dire que gcc4.1 (encore non paru) devrait vraiment améliorer les choses -- j'en sais rien à vrai dire.
Et puis de toute facon, le "combat" d'optimisation de code C compilé est complètement obsolète et réservé à des vieux barbus (j'ai rien contreles vieux barbus). Là où les compilateurs se battent aujourd'hui, c'est plutôt sur le plan de tenter de compiler du C++ (1) rapidement (2) vers du code pas trop inefficace. Et là dessus, gcc a encore bien du travail.
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private>
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
