Identificateur non déclaré, pourquoi ?

Salut,
pourriez vous svp m'aider sur mon code ?

J'ai une erreur identificateur non déclaré :
c:\users\.../documents\visual studio 2008\projects\coursc++\transmission_argument_par_valeur\transmission_argument_par_valeur.cpp(9) : error C2065: 'X'*: identificateur non déclaré

Je ne trouve pas pourquoi, que manque t'il ?


Enfin dans l'affichage du résultat il doit en principe y avoir cela :
Dans SigmaInterval, x ==> 15
Dans SigmaInterval, x ==> 16

D'où vient l'affichage 2 fois ?
D'où vient x ?

merci ;)

le code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

#include <iostream>   using namespace std;   int SigmaInterval(int x, int y) { int s = -1;   if ((x >= 0) && (y > X)) { s = 0; while (x <= y) s += x++; }   cout << "Dans SigmaInterval, x ==>" << x << endl;   return s; }   int main(int argc, char * argv[], char * envp[]) {   int i = 4; int s1 = SigmaInterval(4, 14); int s2 = SigmaInterval(i, 15); int d = s2 - s1;   cout << "s2 ==> " << s2 << '\n' << "s1 ==> " << s1 << '\n' << "d ==> " << d << '\n' << "Dans main, i ==> " << i << endl;   return 0; }

---

Parce que x != X (minuscule / majuscule) ?

PS : Pense aux balises CODE pour entourer ton extrait de code.

Je ne savais pas pour les balises,
Merci pour ton regard de Lynx ;)



Par contre dans le résultat affiché :

Dans SigmaInterval, x ==> 15
Dans SigmaInterval, x ==> 16
etc ...

Pourquoi "Dans SigmaInterval, x ==>" est affiché 2 fois ?

D'où vient x ?

Il est affiché 2 fois parce que tu appelles deux fois ta fonction :

Code:

---

1 2 3

int s1 = SigmaInterval(4, 14); int s2 = SigmaInterval(i, 15);

---

Je comprend pas ta deuxième questions "D'où vient x?"...

x viens de là

Code:

---

1 2	cout << "Dans SigmaInterval, x ==>" << x << endl

---

Nie,

Tu as une drôle de manière de calculer la différence entre 2 valeurs

Code:

---

1 2 3 4 5 6

if ((x >= 0) && (y > X)) { s = 0; while (x <= y) s += x++; }

---

Salut,

Déjà, le problème d'identificateur non déclaré est sans doute du au fait que le deuxième x du test

Code:

---

if((x >= 0) && (y > X))

---

est en majuscule, alors que le seul x déclaré est en minuscule, or, C++ est sensible à la casse (fait la différence entre les majuscules et les minuscules)...

En outre, je me méfie toujours des opérations qui mettent en oeuvre des effets de bords, ce qui fait que j'aurais naturellement tendance à éviter l'écriture proche de

Code:

---

1 2	while (x <= y) s += x++;

---

et de préférer plutôt l'écriture sous la forme de

Code:

---

1 2 3 4 5

while(x<=y) { s+=x; ++x; }

---

qui fournira un résultat équivalent, mais qui est plus verbeuse et donc plus facile à comprendre (et qui ne risque pas de provoquer d'erreur d'interprétation).

Tout pareil que Koala...

Sauf que personnellement... je préfèrerai le calcul mathématique:

Code:

---

1 2 3 4 5 6 7 8 9 10

int Sigma0(int x) { return x * (x + 1) / 2; }   int SigmaInterval(int x, int y) { return Sigma0(max(x,y)) - Sigma0(min(x,y)) }

---

D'autant que ta fonction est fausse (en tout cas, inconsistante):
Chez toi SigmaInterval(1,1) = -1 ????? et SigmaInterval(1,2)=3 !!!
Cela me semble très louche comme résultats (et à mon avis très dangereux)

Je veux dire par là... que intuitivement, je m'arrangerai pour que:
ou bien , a<=b<=c : SigmaInterval(a,c) = SigmaInterval(a,b) + SigmaInterval(b,c) (borne sup exclue)
ou bien, a<b<=c SigmaInterval(a,c) = SigmaInterval(a,b-1) + SigmaInterval(b,c) (borne sup inclue)

Mais, bon...

Citation:

---

Envoyé par koala01

Salut,


En outre, je me méfie toujours des opérations qui mettent en oeuvre des effets de bords, ce qui fait que j'aurais naturellement tendance à éviter l'écriture proche de

Code:

---

1 2	while (x <= y) s += x++;

---

et de préférer plutôt l'écriture sous la forme de

Code:

---

1 2 3 4 5

while(x<=y) { s+=x; ++x; }

---

qui fournira un résultat équivalent, mais qui est plus verbeuse et donc plus facile à comprendre (et qui ne risque pas de provoquer d'erreur d'interprétation).

---

Je suis d'accord pour la x, et j'ai compris pour le double appel de la fonction.
Ce que tu soulignes : c'est bien là toute la problématique de l'optimisation du code, en décomposant c'est plus clair mais le code est moins concis, chaque méthode a avantages et inconvénients ;)
De plus (même si dans cet exemple simple c'est peu important) ++x et x++ n'auront pas le même résultat.

Par contre nicroman : ta méthode mathématique je n'ai pas tout suivi, les maths pour moi remontent à Trés loin (...)

mais par exemple moi je n'écrirai pas return x * (x + 1) / 2 mais plutôt return x * ((x + 1) / 2) , ou return ( x * (x + 1)) / 2 si je me suis trompé sur l'associativité des opérateurs ; en tout cas je trouve que les parenthèses rendent le code plus lisible, ôtent tout doute possible.

-1 tu dis ? j'initialise ainsi pour que dans le cas où le if n'est pas exécuté ce soit visible de suite ;)
Exple si x = 1 et y = 1 , on ne rentre pas dans le if car y n'est pas supérieur à x, il n'y donc pas d'intervalle et s = -1 signale une anomalie (pour un intervalle)


pour ci dessous je ne vois pas où tu veux en venir :
Je veux dire par là... que intuitivement, je m'arrangerai pour que:
ou bien , a<=b<=c : SigmaInterval(a,c) = SigmaInterval(a,b) + SigmaInterval(b,c) (borne sup exclue)
ou bien, a<b<=c SigmaInterval(a,c) = SigmaInterval(a,b-1) + SigmaInterval(b,c) (borne sup inclue)


Quand je demande d'où vient x : pourquoi 15 et 16 ?

Citation:

---

Envoyé par manchette

Je suis d'accord pour la x, et j'ai compris pour le double appel de la fonction.
Ce que tu soulignes : c'est bien là toute la problématique de l'optimisation du code, en décomposant c'est plus clair mais le code est moins concis, chaque méthode a avantages et inconvénients ;)
De plus (même si dans cet exemple simple c'est peu important) ++x et x++ n'auront pas le même résultat.

---

Effectivement, ++x et x++ ne donnent à la base pas le même résultat, mais, sur base du calcul effectué,

Code:

---

1 2	s+=x++; //calcule s+x (en passant une copie de x) puis // incrémente x

---

et

Code:

---

1 2 3

s+=x; //calcule s+x ++x; //incrémente x

---

donnent un résultat tout à fait équivalent.

De plus, s'il est vrai qu'au temps des débuts des compilateur C, de tels sucres syntaxiques étaient utiles pour assurer certaines optimisations, il faut se dire qu'à l'époque actuelle, avec les compilateurs (et surtout les machines) dont on dispose, ce genre de sucre syntaxique n'apporte plus rien du tout, et ce d'autant plus que la post incrémentation produit une copie temporaire de la variable incrémentée, et que cette copie a malgré tout un cout ;):aie:.

Il ne faut pas non plus oublier la fameuse phrase:

Citation:

---

dans, mettons, 95% des cas, les optimisations prématurées sont les routes de tous les maux

---

C'est la raison pour laquelle je n'hésite pas à déclarer bien haut que la première qualité d'un code, avant même de faire ce que l'on attend de lui, est d'être facilement lisible et compréhensible par la personne qui l'a sous les yeux.

S'il n'y a aucune différence entre le binaire créé au départ d'un code proche de

Code:

---

instruction1; instruction2; instruction3;

---

et un code proche de

Code:

---

1 2 3

instruction1; instruction2; instruction3;

---

il y a une différence certaine quant à la facilité avec laquelle le lecteur du code va le comprendre, surtout si instruction1 vient à être une boucle ou un test ou si l'une des instructions utilise un effet de bord.

En effet, la première version va, certes, gagner deux lignes de code (ce qui n'a finalement aucun intérêt), mais le lecteur risque fort, suite à une lecture trop transversale, de "passer à coté" soit de l'effet de bord, soit de l'une ou l'autre instruction, soit, si instruction1 est une boucle ou un test, sur le fait qu'elle (il) ne s'applique qu'à instruction2...

C'est pourquoi, dans une première version du programme, il me semble important de privilégier la (re)lecture et la compréhension du code.

Ce n'est que si, par la suite, benchs à l'appui, on se rend, effectivement compte que le sucre syntaxique envisagé apporte un gain utile / nécessaire non négligeable à l'exécution, on peut effectivement envisager de le garder...

Autrement, il ne sera qu'une source d'erreur potentielle ;)

Je comprend ton approche, et l'évolution des compilateurs et machines , ainsi que les différentes versions du code ;)


me reste à comprendre le résultat pour x (15 et 16)

Citation:

---

Envoyé par manchette

Je comprend ton approche, et l'évolution des compilateurs et machines , ainsi que les différentes versions du code ;)


me reste à comprendre le résultat pour x (15 et 16)

---

C'est le résultat de ce que tu as écrit...

Code:

---

1 2 3 4 5 6 7 8 9 10

if ((x >= 0) && (y > x)) { s = 0; while (x <= y) s += x++; }   cout << "Dans SigmaInterval, x ==>" << x << endl; }

---

Tu n'entre dans le if que si 0<=x<y.
Tu ne fais la boucle que tant que x<=y. Donc tu sort de ta boucle quand x = y+1.
Tu appelles :

Code:

---

1 2 3

int s1 = SigmaInterval(4, 14); int s2 = SigmaInterval(i, 15);

---

Donc dans le premier cas y = 14, donc à la fin de la boucle x = 15.
Dans le second cas, y = 15, donc à la fin de la boucle x = 16.

Tout cela tu aurais pu le voir avec n'importe quel débugger, un point d'arrêt et l'examen de tes variables :?

Citation:

---

Envoyé par manchette

Je comprend ton approche, et l'évolution des compilateurs et machines , ainsi que les différentes versions du code ;)

---

C'est déjà une bonne chose :D

Citation:

---

me reste à comprendre le résultat pour x (15 et 16)

---

Mets toi à la place du processeur et déroule la boucle :D
La situation de départ:

• s = -1
• x = 14
• y = 15

l'exécution

• On passe dans le test x>=0 et x<=y :question: oui (on vient de dire qu'il vaut 14)
• ==> s vaut 0
• doit on entrer dans la boucle (x<=y):question: oui (14 est bien plus petit ou égal à 15)
• ==>s vaut s + x (autrement dit s = 0+14 =... 14)
• ==>x est incrémenté (après avoir servi de valeur): x = 15
• doit on entrer une nouvelle fois dans la boucle dans la boucle (x<=y):question: oui (15 est bien plus petit ou égal à 15)
• ==> s vaut s+x (autrement dit: s= 14+15 = 29)
• ==> x est incrémenté (après avoir servi de valeur) : x = 16
• doit on entrer une fois supplémentaire dans le boucle:question: non (16 est plus grand que 15)
• ==>on quitte la boucle et le test ==>on arrive à l'affichage

le résultat une fois sorti du test

• s = 29
• x = 16
• y = 15

Et le problème de compréhension est, justement, l'exemple type de ce que j'explique sur le danger d'écrire des instructions ayant des effets de bord ;) (parce que, effectivement, si on venait à écrire s += ++x; le résultat serait différent ;))

Ayé :yaisse2:

:merci:

Pense à mettre en :resolu: ;)