Bonjour, Voila je commence a coder sous C et j'ai une fonction qui patine sans que j'en trouve l'erreur...
Alors j'espère que vous pourrez me faire par de vos lumière.
Cordialement
Voici le code ...
###################### les fichiers source ###############
Main.c #
########
printf("Longueur du mot secre : ");
Etoile_Secr(motSecret);
printf("Propose une lettre : ");
lettreTap = lireCaractere();
printf("Etat du mot secre : ");
printf("%s",Result_Trouve_Cache_Save(motSecret,lettreTap));
return 0;
}
###########
Fonction.c #
###########
char lireCaractere()
{
char caractere = 0;
caractere = getchar(); // On lit le premier caractère
caractere = toupper(caractere); // On met la lettre en majuscule si elle ne l'est pas déjà
// On lit les autres caractères mémorisés un à un jusqu'à l'\n (pour les effacer)
while (getchar() != '\n') ; // il y a un ";" car c'est une boucle minimaliste "Technique de programmeur"
return caractere; // On retourne le premier caractère qu'on a lu
}
void Etoile_Secr(char* Tab)
{
int i = 0;
for(i=0;i<Tab[i];i++)
{
printf("*");
}
printf("\n");
}
char* Result_Trouve_Cache_Save(char* Tab,char lettre)
{
int i = 0;
char* copieTab = 0;
int longueurChaine = 0;
longueurChaine = strlen(Tab);
copieTab = malloc(longueurChaine);
if (copieTab == 0)
{
exit(0);
}
for (i = 0 ; i < Tab[i] ; i++)
{
if (lettre == Tab[i])
{
copieTab[i] = lettre;
printf("%s\n",copieTab); // J'ai testé pour voir et je comprend pas
}
else
{
copieTab[i] = '*';
printf("%s\n",copieTab); // J'ai testé pour voir et je comprend pas
}
}
// free(copieTab)
return copieTab; // Est-ce que le return suffirait ?
}
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni -ansi ou stdÉ9, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode "de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA -- ne sera jamais bien portable, mais que des choses comme les operations atomiques de C11 ou les literaux unicodes le deviendront assez rapidement.)
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
In article <je7cc3$12hi$1@saria.nerim.net>, Marc Espie <espie@nerim.net> wrote:
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni
-ansi ou std=c99, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on
veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode
"de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du
code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA --
ne sera jamais bien portable, mais que des choses comme les operations
atomiques de C11 ou les literaux unicodes le deviendront assez
rapidement.)
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni -ansi ou stdÉ9, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode "de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA -- ne sera jamais bien portable, mais que des choses comme les operations atomiques de C11 ou les literaux unicodes le deviendront assez rapidement.)
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni -ansi ou stdÉ9, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode "de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA -- ne sera jamais bien portable, mais que des choses comme les operations atomiques de C11 ou les literaux unicodes le deviendront assez rapidement.)
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
In article <pxb4nw8wvbp.fsf@bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
espie@lain.home (Marc Espie) writes:
In article <je7cc3$12hi$1@saria.nerim.net>, Marc Espie
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni
-ansi ou stdÉ9, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on
veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode
"de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du
code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA --
ne sera jamais bien portable, mais que des choses comme les operations
atomiques de C11 ou les literaux unicodes le deviendront assez
rapidement.)
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent
a rien de connu, en particulier, me fait me poser de serieuses questions
sur ce que le comite avait fume ce jour-la.
Par contre, je remarque que tu ne sembles pas recommander -pedantic ni -ansi ou stdÉ9, pourquoi ?
Parce que ceux-la sont moins neutres, et vont dependre un peu de ce qu'on veut faire exactement...
En particulier, je considere qu'on est toujours dans une periode "de transition" (qui s'acheve cependant), ou on peut avoir a ecrire du code qui sera C89/C99 ou autre chose au milieu.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
(Je parie que tout ce qui est devenu optionel en C11 -- comme les VLA -- ne sera jamais bien portable, mais que des choses comme les operations atomiques de C11 ou les literaux unicodes le deviendront assez rapidement.)
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Marc
Marc Espie wrote:
In article ,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes) ou d'utiliser d'autres noms. Et comme autres noms, ils n'ont pas fait très original, ils ont changé le préfixe pthread_ en thrd_ (thread_ aurait donné trop de conflits avec de l'existant), mais les suffixes sont restés _create, _detach, _join, _exit, _yield, etc.
Je ne comprends pas bien ta critique (pourtant il doit y avoir plein de bonnes raisons de critiquer C11, y compris sur les threads).
Marc Espie wrote:
In article <pxb4nw8wvbp.fsf@bourguet.org>,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent
a rien de connu, en particulier, me fait me poser de serieuses questions
sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant,
mais on peut comprendre que ça pose des problèmes) ou d'utiliser
d'autres noms. Et comme autres noms, ils n'ont pas fait très original,
ils ont changé le préfixe pthread_ en thrd_ (thread_ aurait donné trop
de conflits avec de l'existant), mais les suffixes sont restés
_create, _detach, _join, _exit, _yield, etc.
Je ne comprends pas bien ta critique (pourtant il doit y avoir plein
de bonnes raisons de critiquer C11, y compris sur les threads).
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes) ou d'utiliser d'autres noms. Et comme autres noms, ils n'ont pas fait très original, ils ont changé le préfixe pthread_ en thrd_ (thread_ aurait donné trop de conflits avec de l'existant), mais les suffixes sont restés _create, _detach, _join, _exit, _yield, etc.
Je ne comprends pas bien ta critique (pourtant il doit y avoir plein de bonnes raisons de critiquer C11, y compris sur les threads).
espie
In article <je7j9l$ctq$, Marc wrote:
Marc Espie wrote:
In article ,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite avec un autre mecanisme.
C'est deja suffisamment le boxon entre C et C++, c'est peut-etre pas la peine de faire encore dans la difference gratuite d'avec POSIX, si ?
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus *aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de namespaces. Les trucs a base de preprocesseur pour limiter les mots-cle et autres vasouilleries, ca va bien un moment, mais faudrait reconnaitre que le seul gros probleme de portabilite qui reste aujourd'hui en C, c'est ces satanes problemes de version et le fait que tout se melange entre norme, implementation, et bibliotheques tierces qui se marchent dessus.
In article <je7j9l$ctq$1@news-rocq.inria.fr>,
Marc <marc.glisse@gmail.com> wrote:
Marc Espie wrote:
In article <pxb4nw8wvbp.fsf@bourguet.org>,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent
a rien de connu, en particulier, me fait me poser de serieuses questions
sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant,
mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite
avec un autre mecanisme.
C'est deja suffisamment le boxon entre C et C++, c'est peut-etre pas la
peine de faire encore dans la difference gratuite d'avec POSIX, si ?
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus
*aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de
namespaces. Les trucs a base de preprocesseur pour limiter les mots-cle
et autres vasouilleries, ca va bien un moment, mais faudrait reconnaitre
que le seul gros probleme de portabilite qui reste aujourd'hui en C, c'est
ces satanes problemes de version et le fait que tout se melange entre norme,
implementation, et bibliotheques tierces qui se marchent dessus.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite avec un autre mecanisme.
C'est deja suffisamment le boxon entre C et C++, c'est peut-etre pas la peine de faire encore dans la difference gratuite d'avec POSIX, si ?
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus *aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de namespaces. Les trucs a base de preprocesseur pour limiter les mots-cle et autres vasouilleries, ca va bien un moment, mais faudrait reconnaitre que le seul gros probleme de portabilite qui reste aujourd'hui en C, c'est ces satanes problemes de version et le fait que tout se melange entre norme, implementation, et bibliotheques tierces qui se marchent dessus.
Samuel DEVULDER
Le 06/01/2012 14:45, Olivier Miakinen a écrit :
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la boucle du point de vu des performances. On passe facilement d'un algo rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle avec ce genre de trucs.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation ne sert à rien (on ne lit pas cette valeur d'initialisation), et d'autre part il y a un problème de typage. Je suppose que c'est à mettre en relation avec la mauvaise codeur.
sam.
Le 06/01/2012 14:45, Olivier Miakinen a écrit :
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire
i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la
boucle du point de vu des performances. On passe facilement d'un algo
rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle
avec ce genre de trucs.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation
ne sert à rien (on ne lit pas cette valeur d'initialisation), et
d'autre part il y a un problème de typage. Je suppose que c'est à
mettre en relation avec la mauvaise codeur.
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la boucle du point de vu des performances. On passe facilement d'un algo rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle avec ce genre de trucs.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation ne sert à rien (on ne lit pas cette valeur d'initialisation), et d'autre part il y a un problème de typage. Je suppose que c'est à mettre en relation avec la mauvaise codeur.
sam.
espie
In article <4f0754bf$0$10605$, Samuel DEVULDER wrote:
Le 06/01/2012 14:45, Olivier Miakinen a écrit :
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la boucle du point de vu des performances. On passe facilement d'un algo rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle avec ce genre de trucs.
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant dans le cadre de la boucle et de le sortir du corps.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation ne sert à rien (on ne lit pas cette valeur d'initialisation), et d'autre part il y a un problème de typage. Je suppose que c'est à mettre en relation avec la mauvaise codeur.
Ce code est tellement faux que personne n'a regarde tres en detail. Le seul conseil qui me semblait pertinent, c'etait "active les warnings, lit ce que te dit ton compilo, corrige toutes les erreurs evidentes, et on en reparle".
In article <4f0754bf$0$10605$426a34cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> wrote:
Le 06/01/2012 14:45, Olivier Miakinen a écrit :
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire
i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la
boucle du point de vu des performances. On passe facilement d'un algo
rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle
avec ce genre de trucs.
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo
a parfaitement le droit de detecter si le resultat est constant dans le
cadre de la boucle et de le sortir du corps.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation
ne sert à rien (on ne lit pas cette valeur d'initialisation), et
d'autre part il y a un problème de typage. Je suppose que c'est à
mettre en relation avec la mauvaise codeur.
Ce code est tellement faux que personne n'a regarde tres en detail.
Le seul conseil qui me semblait pertinent, c'etait "active les warnings,
lit ce que te dit ton compilo, corrige toutes les erreurs evidentes,
et on en reparle".
In article <4f0754bf$0$10605$, Samuel DEVULDER wrote:
Le 06/01/2012 14:45, Olivier Miakinen a écrit :
C'est quoi ce « i< Tab[i] » ? Tu voulais peut-être écrire i< strlen(Tab) ?
Nota: C'est pas terrible mettre un strlen() dans la condition de la boucle du point de vu des performances. On passe facilement d'un algo rapide linéaire en un truc en O(n^2) qui ne va pas passer à l'échelle avec ce genre de trucs.
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant dans le cadre de la boucle et de le sortir du corps.
Nota2: je suis surpris que personne n'ait fait remonter un pb sur:
char lettreTap = "";
Qu'est ce le codeur a voulu faire ici? D'une part l'initialisation ne sert à rien (on ne lit pas cette valeur d'initialisation), et d'autre part il y a un problème de typage. Je suppose que c'est à mettre en relation avec la mauvaise codeur.
Ce code est tellement faux que personne n'a regarde tres en detail. Le seul conseil qui me semblait pertinent, c'etait "active les warnings, lit ce que te dit ton compilo, corrige toutes les erreurs evidentes, et on en reparle".
Xavier Roche
Le 06/01/2012 21:24, Marc Espie a écrit :
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure" (__attribute__ ((pure)) ; <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le compilateur rattrape les bêtises derrière.
Le 06/01/2012 21:24, Marc Espie a écrit :
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo
a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure"
(__attribute__ ((pure)) ;
<http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le
compilateur rattrape les bêtises derrière.
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure" (__attribute__ ((pure)) ; <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le compilateur rattrape les bêtises derrière.
Marc
Marc Espie wrote:
In article <je7j9l$ctq$, Marc wrote:
Marc Espie wrote:
In article ,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite avec un autre mecanisme.
Bon, ok, ils ont juste recopié la bibliothèque de threads de Dinkumware...
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus *aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de namespaces.
préfixer tous les noms par un une chaîne commune, c'est un mécanisme qui existe déjà.
Marc Espie wrote:
In article <je7j9l$ctq$1@news-rocq.inria.fr>,
Marc <marc.glisse@gmail.com> wrote:
Marc Espie wrote:
In article <pxb4nw8wvbp.fsf@bourguet.org>,
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent
a rien de connu, en particulier, me fait me poser de serieuses questions
sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant,
mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite
avec un autre mecanisme.
Bon, ok, ils ont juste recopié la bibliothèque de threads de Dinkumware...
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus
*aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de
namespaces.
préfixer tous les noms par un une chaîne commune, c'est un mécanisme
qui existe déjà.
Ou est-ce que tu place C11, entre C89 et C99 ou bien ailleurs?
Pour l'instant, dans #fail.
la "nouvelle" description des threads, avec des noms qui ne ressemblent a rien de connu, en particulier, me fait me poser de serieuses questions sur ce que le comite avait fume ce jour-la.
Le choix était de standardiser les threads posix tels quels (tentant, mais on peut comprendre que ça pose des problèmes)
Lesquels ? je ne vois absolument pas l'interet d'une divergence gratuite avec un autre mecanisme.
Bon, ok, ils ont juste recopié la bibliothèque de threads de Dinkumware...
De toutes facons, de maniere *evidente*, ce qui manque de plus en plus *aujourd'hui* en C, c'est un mecanisme, *quel qu'il soit*, de namespaces.
préfixer tous les noms par un une chaîne commune, c'est un mécanisme qui existe déjà.
Samuel DEVULDER
Le 06/01/2012 21:41, Xavier Roche a écrit :
Le 06/01/2012 21:24, Marc Espie a écrit :
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure" (__attribute__ ((pure)) ; <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le compilateur rattrape les bêtises derrière.
Ben oui: tu changes de compilo et là mystérieusement ton prog se traine et on va accuser à tord le compilo d'être moins bon alors que c'est la sémantique du programme qui est mauvaise. Et cela d'autant plus qu'un test sur tab[i] tout court (ou !=0) suffit (comme indiqué par d'autres) tout en étant parfaitement dans l'esprit de la représentation des chaines en C.
sam.
Le 06/01/2012 21:41, Xavier Roche a écrit :
Le 06/01/2012 21:24, Marc Espie a écrit :
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo
a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure"
(__attribute__ ((pure)) ;
<http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le
compilateur rattrape les bêtises derrière.
Ben oui: tu changes de compilo et là mystérieusement ton prog se traine
et on va accuser à tord le compilo d'être moins bon alors que c'est
la sémantique du programme qui est mauvaise. Et cela d'autant plus
qu'un test sur tab[i] tout court (ou !=0) suffit (comme indiqué par
d'autres) tout en étant parfaitement dans l'esprit de la représentation
des chaines en C.
Meme pas sur, strlen() fait partie de la bibliotheque standard, le compilo a parfaitement le droit de detecter si le resultat est constant
Sous GCC/glibc, la fonction est probablement déclarée "pure" (__attribute__ ((pure)) ; <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>)
Mais c'est amha une très mauvaise idée de code comme ça, même si le compilateur rattrape les bêtises derrière.
Ben oui: tu changes de compilo et là mystérieusement ton prog se traine et on va accuser à tord le compilo d'être moins bon alors que c'est la sémantique du programme qui est mauvaise. Et cela d'autant plus qu'un test sur tab[i] tout court (ou !=0) suffit (comme indiqué par d'autres) tout en étant parfaitement dans l'esprit de la représentation des chaines en C.
sam.
Samuel DEVULDER
Le 06/01/2012 21:24, Marc Espie a écrit :
Ce code est tellement faux que personne n'a regarde tres en detail.
C'est pas faux.
Le seul conseil qui me semblait pertinent, c'etait "active les warnings, lit ce que te dit ton compilo, corrige toutes les erreurs evidentes, et on en reparle".
oui je crois que c'est ce qu'il y a de plus raisonnable. Par contre il n'est pas évident que l'auteur se rende compte à quel point le prog est buggé quand il pense que "c'est surement un petit quelque chose de rien du tout mais qui m'échappe". En vrai tout le code est à revoir et pas seulement 2 ou 3 tour de vis anecdotiques dans les coins.
Courage à Clapannac, il lui reste encore beaucoup à pratiquer, débugger et comprendre ce qu'il se passe pour maitriser ce qu'il a appris probablement machinalement et sans vraiment réfléchir à ce que le code fait. En témoigne la présence de "i<tab[i]" dans la boucle qui est un mélange entre les deux types de parcours de chaines. Il a du se dire qu'il faut un "<" comme dans for(i=0; i<10; i++) mais il a aussi tu se rappeler que pour les chaines tab[i] apparait quelque part.. d'où le très curieux "i<tab[i]".
Rien n'est perdu, mais il lui reste encore du travail pour écrire précisément un code qui fait ce qu'il a en tête.
sam.
Le 06/01/2012 21:24, Marc Espie a écrit :
Ce code est tellement faux que personne n'a regarde tres en detail.
C'est pas faux.
Le seul conseil qui me semblait pertinent, c'etait "active les warnings,
lit ce que te dit ton compilo, corrige toutes les erreurs evidentes,
et on en reparle".
oui je crois que c'est ce qu'il y a de plus raisonnable. Par contre
il n'est pas évident que l'auteur se rende compte à quel point le
prog est buggé quand il pense que "c'est surement un petit quelque
chose de rien du tout mais qui m'échappe". En vrai tout le code est
à revoir et pas seulement 2 ou 3 tour de vis anecdotiques dans les
coins.
Courage à Clapannac, il lui reste encore beaucoup à pratiquer,
débugger et comprendre ce qu'il se passe pour maitriser ce qu'il a
appris probablement machinalement et sans vraiment réfléchir à ce que
le code fait. En témoigne la présence de "i<tab[i]" dans la boucle
qui est un mélange entre les deux types de parcours de chaines. Il
a du se dire qu'il faut un "<" comme dans for(i=0; i<10; i++) mais il
a aussi tu se rappeler que pour les chaines tab[i] apparait quelque
part.. d'où le très curieux "i<tab[i]".
Rien n'est perdu, mais il lui reste encore du travail pour écrire
précisément un code qui fait ce qu'il a en tête.
Ce code est tellement faux que personne n'a regarde tres en detail.
C'est pas faux.
Le seul conseil qui me semblait pertinent, c'etait "active les warnings, lit ce que te dit ton compilo, corrige toutes les erreurs evidentes, et on en reparle".
oui je crois que c'est ce qu'il y a de plus raisonnable. Par contre il n'est pas évident que l'auteur se rende compte à quel point le prog est buggé quand il pense que "c'est surement un petit quelque chose de rien du tout mais qui m'échappe". En vrai tout le code est à revoir et pas seulement 2 ou 3 tour de vis anecdotiques dans les coins.
Courage à Clapannac, il lui reste encore beaucoup à pratiquer, débugger et comprendre ce qu'il se passe pour maitriser ce qu'il a appris probablement machinalement et sans vraiment réfléchir à ce que le code fait. En témoigne la présence de "i<tab[i]" dans la boucle qui est un mélange entre les deux types de parcours de chaines. Il a du se dire qu'il faut un "<" comme dans for(i=0; i<10; i++) mais il a aussi tu se rappeler que pour les chaines tab[i] apparait quelque part.. d'où le très curieux "i<tab[i]".
Rien n'est perdu, mais il lui reste encore du travail pour écrire précisément un code qui fait ce qu'il a en tête.
