Discussion :

[Liamp]

Bonjour, j'ai un petit problème avec mon programme que je dois faire pour l'école : pour le case 2 si le numéro de l'étape entré au début est différent de 0 ainsi que pour le case 3 il me retourne 0 comme valeur ... Est ce que vous savez m'aidez ?
Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
#include <iostream>
#include <cmath>
using namespace std;
int menu () ;
int cote (int etape) ;
float perim (int etape , float longueur) ;
float surface (int etape, float longueur) ;
int main()
{
    int N ;
    int c ;
    int compt =0 ;
    float L, R2, R3 ;
    int R1;
 
    do {
        cout << "Nombre d'"<<"\x82"<<"tapes ?"<<endl;
        cin >> N;
        cout << "Longueur du cot"<<"\x82"<<" ?"<<endl;
        cin >> L ;
        compt++ ;
} while ((N < 0 || L <= 0) && compt < 3 ) ;
    if (compt < 3) {
 
    c =  menu() ;
 
    switch (c) {
        case 1 :
            R1 = cote(N);
            cout <<" Le nombre de c"<<"\x93"<<"t"<<"\x82"<<" = "<<R1<<endl ;
            break ;
 
        case 2 :
            R2 = perim (N, L) ;
            cout <<" Le p"<<"\x82"<<"rim"<<"\x8A"<<"tre = "<<R2<<endl ;
            break;
 
        case 3 :
            R3 = surface (N, L) ;
            cout <<" La surface = "<<R3<<endl ;
            break;
        }
 
 
}
 
}
 
int menu () {
    int choix ;
    cout <<"Choississez une option pour le flocon de Koch :" <<endl ;
    cout <<"1 : calculer le nombre de c"<<"\x93"<<"t"<<"\x82"<<"s " <<endl ;
    cout <<"2 : calculer le p"<<"\x82"<<"rim"<<"\x8A"<<"tre  " <<endl ;
    cout <<"3 : calculer la surface" <<endl ;
    cin >> choix;
    return choix;
}
 
int cote (int etape) {
    int P = 1 ;
    int X ;
    int i ;
    if (etape == 0) {
            X = 3 ;
 
    }
    else {
        for(i=0; i<etape ; i++) {
            P = P * 4;
            }
        X = 3 * P ;
    }
        return X;
 
}
 
float perim (int etape , float longueur) {
    float P = 1, X ;
    int i ;
    if (etape == 0) {
            X = 3 * longueur ;
    }
    else {
            for(i=0; i<etape ; i++) {
                P = P * (3/4);
            }
                X = 3 * longueur * P;
 
            }
        return X;
}
float surface(int etape, float longueur){
    float P = 1, X ;
        int i ;
        if (etape == 0) {
            X = sqrt(3)/4 * longueur * longueur ;
        }
    else {
        for(i=0; i<etape ; i++) {
            P = P * (4/9);
        }
            X = sqrt(3)/4 * longueur * longueur * (1+1/3 * ((1-P)/ (1- 4/9))) ;
 
        }
        return X;
}

[koala01]

Salut,

Pourrais tu juste corriger ton intervention en entourant ton code des balises ( [ code ] en ouverture et [ / code ], le tout sans les espaces ) telles que rajoutée lorsque tu clique sur le bouton #, en prenant soin de lui donner la même mise en forme que celle que tu a dans ton propre code Cela facilitera la vie de tout le monde (et la compréhension de ceux qui seront en mesure de t'aider

A partir de là, il y aura quelques remarques à faire ... Je vais déjà prendre un peu d'avance :

1- On n'utilise JAMAIS la directive using namespace std; :

Cette directive a été proposée en 1998, lorsque le comité de standardisation a décidé de faire passer le contenu de la bibliothèque standard dans l'espace de noms std, parce qu'il y avait déjà "une grosse base de code", qui utilisait la bibliothèque standard telle qu'elle apparaissait avant ce changement, et qu'il fallait faire en sorte que "ce code existant" puisse compiler avec "le moins de modifications possibles".

On ne peut décemment pas dire que le code que tu écris cette semaine soit du "vieux code" qui existait déjà en ... 1998

De plus, cette directive occasionne bien plus de problème qu'elle n'en résout. Essayes simplement de compiler un code pourtant aussi simple que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <iostream>
using namespace std;
int main(){
    int cout{15};
    cout<<"le cout est de "<<cout<<" euros\n";
    return 0;
}

pour t'en convaincre

2- Essaye de choisir des noms de variables, de types de données et de fonctions explicites: qui indiquent sans l'ombre d'un doute à quel usage tu les destines.

Fut un temps, mais je parle d'un temps que même les moins de trente ans ne peuvent pas connaître, où le moindre caractère d'espace disque coûtait la moitié d'un bras.

A l'heure actuelle, s'il y a bien une chose qui ne coûte quasiment plus rien, c'est bien l'espace disque

Il n'y a donc absolument plus aucun sens à utiliser des noms de variables à une seule lettre, à moins qu'il n'y ait une bonne raison de le faire.

Mais, à la lecture de ton code, je n'ai aucune idée de l'usage auquel tu destine tes données N, L,c, R1, R2 et R3.

Et c'est d'autant plus vrai que N est un entier, mais que L est un réel, et que R2 et R3 sont des réels, mais que R1 est un entier...

Comment veux tu arriver à ne pas te tromper, et à essayer d'utiliser L ou R1 là où tu devrais utiliser N ou R2 / R3

La programmation consiste à donner (un semblant d') intelligence -- parfois très complexe, je te l'accorde -- à la chose la plus idiote que l'on puisse trouver sur terre!

Le QI de base d'un ordinateur est encore plus faible de celui de l’amibe, car, elle, au moins, elle est en mesure prendre la décision de se scinder en deux quand elle devient trop grosse. L'ordinateur n'est même pas capable de prendre ce genre de décision si tu ne lui dit pas comment s'y prendre et dans quelles conditions!

Une grosse partie du métier de développeur -- et c'est sans doute la plus difficile -- consiste à se faire "aussi idiot" que ce que ne l'est réellement un ordinateur. Et cela implique que ton code doit refléter cet état d'esprit.

Si tu commence à créer des données qui ont "presque le même nom" mais qui sont de types différents, il ne faudra pas deux semaines avant que tu perde complètement la boule

2b- Essayes, par la même occasion, de choisir une convention de nommage que tu utiliseras pour toutes les variables que tu devra déclarer sur l'ensemble du projet; et fait pareil (même si la convention est un peu différente) pour les types de données et les fonctions :

Il n'y a rien de plus distrayant que d'avoir un nom de variable écrit en majuscule (N), un autre écrit exclusivement en minuscule (c ou compt) et, pourquoi pas, un troisième pour lequel on mélangerait un peu les deux (laVariable).

Ton projet est tout simple (il fait à peine plus d'une centaine de lignes)... Mais quand tu arriveras sur des projets moyennement à très complexes (plusieurs ... centaines de milliers de lignes), tu seras très content de savoir très précisément distinguer ce qui correspond à une donnée et ce qui correspond à un type de donnée

3- Ne déclares pas tes données en début de bloc : déclares les au plus proche de leur première utilisation:

Il n'y a rien à faire, lorsque tu ne déclares que des données que tu es sur le point d'utiliser, tu évites déjà grandement de déclarer une donnée dont "tu crois que tu auras besoin" (mais que tu n'utiliseras au final pas).

Mais, en plus, cela te permet -- le cas échéant -- de fournir directement la valeur adéquate à cette donnée, même si elle doit être calculée à partir d'autre données (que tu auras forcément déjà utilisée, entre autres, pour leur donner leur propre valeur adéquate).

3b - respecte impérativement la règle "une déclaration de variable == une ligne".

Si tu as deux variables (de même type), cela se fait donc en ... deux lignes:

on ne va pas écrire un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int a, b;

mais bien sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a;
int b;

4- On dit souvent que

100% des bugs trouvent leur origine dans l'interface entre la chaise et le clavier

Je le dis souvent plus crûment sous la forme de

l'utilisateur est un imbécile distrait qui n'attend que l'occasion de faire une connerie

Mais le résultat est toujours le même : tu ne peux absolument pas faire confiance à l'utilisateur pour introduire exactement la valeur du type particulier à laquelle tu t'attends.

Tu tournes cela comme tu veux, mais, à chaque fois que tu demande à l'utilisateur d'introduire une donnée, il faut la vérifier plutôt deux fois qu'une (il y a moyen de le faire, ne t'en fais pas ), des fois qu'il décide d'introduire "3.1415926" ou "hello world" alors que tu attend qu'il introduise un entier.

Ton application sera "correcte et sans bug" le jour où elle sera en mesure de réagir correctement (en engueulant l'utilisateur et en lui demandant d'introduire un entier ) face à une ignominie pareille

5- Ne te fais pas trop chier avec les caractères accentués:

Si tu tiens à ce que l'affichage se fasse en français, utilise les caractères non accentués (d'autant plus que la valeur hexadécimale des différents caractères accentués dépend fortement du "code-page" utilisé) et, au pire, essaye de fournir un affichage en anglais (qui n'utilise aucun caractère accentué), si tu tiens à ce que l'orthographe soit correcte

Plus tard, lorsque tu commencera à utiliser une bibliothèque dite "d'IHM" (Interface Homme Machine) ou dite "graphique", la table de caractères sera différentes : Ce sera une table de caractères "multibytes" pour laquelle il n'y a -- a priori -- aucun problème, et tu pourras utiliser les caractères accentués autant que tu le souhaite

Mais, dans un premier temps, pour l'affichage console, tu te "casse la tête" pour pas grand chose

6- N'oublie pas d'indenter ton code :

Comme je l'ai dit en (2), nous ne sommes plus vraiment à un caractère près dans le code... Autant en profiter pour faire en sorte -- entre autres -- de repérer "facilement" les différents blocs auxquels nous sommes confrontés, en faisant en sorte que la première lettre de chaque ligne "un peu décalée" par rapport au bloc auquel elle se rapporte

Quant tu auras corrigé tout cela, nous pourrons commencer à nous intéresser au noeud de ton problème. Et il y a même pas mal de chances pour que le simple fait d'apporter les corrections suggérées te permettent de résoudre ton problème par toi-même

[Liamp]

En fait, on nous a appris à mette ce fameux using namespace std; Donc en effet on apprend du vieux code (je ne suis pas en école d'informatique) . Je ne savais pas comment le mettre en couleur donc je le ferais la prochaine fois pareil car j'ai finalement résolu le problème . J'essayerais d'appliquer tes autres conseil pour mes prochaines programmation . En attendant je ne sais pas comment clore une discussion ... ?
Voila le code final en passant pour montrer que j'ai appliqué la plupart de tes conseils O

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <iostream>
#include <math.h>
using namespace std;
 
void menu(int &choix);
void nombrecote(int N,int &nbrc);
void perimetre(int N, int nbrc, float L, float &p);
void surface(int N, float L,float temp, float &A);
 
int main()
{
	int etape,compt=0,choix,nbrc=0;
	float Longueur,p=0,A=0,temp=0;
 
	do {
		cout << "entrez un entier N" << endl;
		cin >> etape;
		cout << "entrez un reel L" << endl;
		cin >> Longueur;
		compt++;
	} while ((etape < 1 || Longueur <= 0) && compt < 3);
	if(compt<3)
	{
		cout << "N=" << etape << endl;
		cout << "L=" << Longueur << endl;
		menu(choix);
		switch (choix)
		{
		case 1:
			nombrecote(etape, nbrc);
			cout << "nombre de cotes = " << nbrc << endl;
			break;
		case 2:
			perimetre(etape,nbrc,Longueur,p);
            cout << "le perimetre = " << p << endl;
			break;
		case 3:
			surface(etape,Longueur,temp,A);
            cout << " aire = " << A << endl;
			break;
 
		}
 
 
	}
	else
	{
		;
	}
	}
 
void menu(int &choix)
{
	cout << "choisissez une operation " << endl;
	cout << "1. calcul du nombre de cotes" << endl;
	cout << "2. calcul du perimetre " << endl;
	cout << "3. calcul de l'aire " << endl;
	cin >> choix;
}
 
void nombrecote(int etape,int &nbrc)
{
	nbrc = 3 * pow(4, etape);
}
void perimetre(int etape,int nbrc,float Longueur, float &p )
{
	nombrecote(etape, nbrc);
 
	p = (float)nbrc * (Longueur / pow(3, etape));
}
void surface(int etape, float Longueur,float temp, float &A)
{
	temp =((sqrt(3)/4)*pow(Longueur,2)) ;
	A = temp * (1 + (1 / 3)*((1 - pow((4 / 9), (float)etape)) / 1 - (4 / 9)));
}

[koala01]

Ah, avoue que c'est tout de suite beaucoup plus clair,non (bon, je chipote, mais il y a encore les deux cout<< des case 2:et case 3: qui devraient -etre encore un peu décalés, pour se retrouver au même niveau "que le reste". Quant à la dernière accolade fermante de la fonction main(), ce serait pas mal si elle se trouvait "tout à fait à gauche" )

En fait, on nous a appris à mette ce fameux using namespace std; Donc en effet on apprend du vieux code (je ne suis pas en école d'informatique)

Et encore, ce n'est pas la pire des mauvaises habitudes que tu puisse prendre ... quel que soit le tutoriel sur lequel tu planches

D'une "certaine manière", je comprends parfaitement les raisons qui poussent les auteurs de tutoriels et de cours à utiliser cette directive, parce que, d'un point de vue purement didactique, elle permet à l'auteur de ne pas devoir parler des espaces de noms dés le départ...

Mais il y a une différence très nette entre "comprendre" les motivations des gens et celle de les "accepter" : le système d'espaces de noms est un élément essentiel du langage, même si tu ne t'en rends pas forcément compte aujourd'hui...

Or, quand tu te retrouveras avec un projet de plusieurs (centaines de) milliers de lignes de code, qui utilise cinq ou six bibliothèques différentes qui exposent toutes une fonctionnalité portant le même nom, tu comprendra pourquoi on a tendance à y être opposé

Tout cela pour dire qu'on ne peut pas dans le même temps être et avoir été : mon rôle à moi, "vieux de la vieille", c'est de m'assurer que tu prenne les bonnes habitudes, pour ne pas avoir à perdre les mauvaises

Bien pire donc que cette habitude qu'il ne faut pas prendre, c'est l'habitude de déclarer deux (ou pire : plusieurs) variables sur la même ligne !!! (le point 3b de mon intervention, que j'ai corrigée pour effectivement présenter un exemple), et, accessoirement, les conventions de nommage.

Car on retrouve encore Longueur (avec un L majuscule), A (qui est une majuscule), p (qui est une minuscule) et temp tout en minuscule...

Je me fous parfaitement de savoir si tu décideras de mettre une majuscule ou une minuscule en première (et, le cas échéant, en seule) lettre d'une variable. Ce que je veux -- j'irais presque jusqu'à l'exiger si j'étais ton prof -- c'est que tous les noms de variable suivent le "même schéma"!!!

Si tu décides de mettre une majuscule comme première lettre du nom de variable, ca me va très bien!!! Pour autant que ... les 10 000 noms de variables qui seront disséminés dans ton code respectent le même schéma.

Crois moi bien quand je te dis que, tant que tu ne travailleras pas avec moi, je n'aurai rien à gagner à t'imposer ce genre de discipline! Si j'insiste tellement sur ce point, c'est parce que je sais que cette discipline va te faciliter la vie... dés demain ou après-demain, et qu'elle va le faire tout au long de "ta vie de développeur" (que je t'espère "la plus longue possible" )

Mais bon, passons à la suite du programme.

Maintenant que ton code est correctement présenté, nous pouvons commencer à discuter du code en lui-même

Et la première chose, c'est que, si le compilateur se plaint qu'une fonction ne renvoie rien à lors qu'elle est sensée renvoyer une valeur, c'est parce qu'elle ne termine par par un instruction introduite par ... le mot clé returnPrenons exemple de la fonction main, dont le prototype est int main():

Le mot clé (int) est un mot clé qui représente une "valeur numérique entière" et qui, lorsqu'il précède le nom d'une fonction (main dans le cas présent) indique au compilateur que "la fonction en question doit renvoyer une valeur du type indiqué" (int, qui est une valeur numérique entière, dans le cas présent).

C'est d'autant plus vrai pour la fonction main qu'elle sert "de point d'entrée" dans ton programme, qui sera appelé à partir du système d'exploitation (je simplifie à outrance ici, mais soit).

Or, si la fonction main agit comme "un point d'entrée", elle agit aussi -- forcément -- comme "point de sortie", car, lorsque l'exécution atteindra la dernière accolade fermante de la fonction main, ton programme sera arrêté.

Le truc, c'est que le système d'exploitation aime bien "foutre son nez partout", et que, quand un programme s'arrête, il aime bien se savoir si le programme en question a pu se "dérouler correctement" (et être mené "à son terme"), s'il y a eu des avertissements lors de l'exécution du programme ou même -- bien pire encore -- si le programme "a planté", qu'il a rencontré une erreur, et qu'il n'a donc pas eu d'autre choix que de s'arrêter "brutalement", à un endroit du code qui n'était pas prévu à cet usage.

Pour indiquer au système d'exploitation que "tout s'est bien déroulé", on fait en sorte que la dernière instruction exécutée par la fonction main soit...return 0;.

Si tu place "cette simple instruction", juste entre les deux accolades que l'on trouves aux lignes 58 et 59 de ta dernière intervention, cela devrait déjà résoudre quelques problèmes.

Notes au passage que le else juste avant la fin de la fonction main n'a absolument aucune utilité, vu qu'il ne doit rien faire si compt est plus grand ou égal à trois...

Car, l'une des règles que l'on essaye de suivre nous a été dictée par Einstein lui-même:

Il faut rendre les choses aussi complexes que nécessaire, mais guère plus

Il ne sert donc à rien d'ajouter du code qui ne fait strictement rien si le seul résultat est de rendre le "code plus complexe que nécessaire".

Or, il n'y a rien à faire : ajouter du code augmente -- forcément -- la complexité du code. Si le code en question ne sert à rien ... Bah, tu vas en tirer toi-même la conséquence logique, non

Pour le reste:

La notion de référence est sans doute tout à la fois la meilleure et la pire des fonctionnalités (porpres au langage) que l'on puisse trouver.

C'est la meilleure des choses car elle permet de mettre en place des mécanismes dont tu n'as sans doute même pas encore idée (mais ne t'en fais pas : cela viendra en son temps ). Mais c'est la pire des choses car elle permet -- justement -- de mettre en place des mécanismes auxquels il vaut très largement mieux d'éviter d'avoir recours si l'on n'a pas d'excellentes raison d'y avoir recours.

L'un de ces mécanismes auxquels il est préférable d'éviter d'avoir recours est ce que l'on appelle les "effets de bord".

Par principe (discutable, et plein d'exceptions, si tu y tiens), chaque fonction devrait -- idéalement -- être "totalement indépendant" (aux limites imposées par le besoin d'avoir recours à des données externes) et "strictement confiné" : ce qui se passe dans la fonction ... reste dans la fonction. A une exception près : on peut décider de renvoyer une valeur (calculée par la fonction) au moyen du type de retour de la fonction (et de ce fameux mot clé return.

Les références (transmis comme paramètres à une fonction) "brisent" ce "système de confinement" (surtout en cas de référence non constate), car le paramètre transmis sous forme de référence est alors considéré comme un alias (un autre nom, strico sensu) de la donnée qui a été transmise lors de l'appel. Et du coup, toutes les modifications qui pourront être apportées à ce paramètre seront répercutées au niveau de la "donnée d'origine".

C'est -- typiquement -- ce que l'on appelle un "effet de bord".

Tu me demanderas sans doute "oui, mais, pourquoi un tel effet poserait-il problème " Hé bien, pour répondre à ta question, je vais te proposer deux codes dont je vais te demander de trouver la différence:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
void foo(int i) ; // sans effet de bord
void bar(int & i) ; // avec effet de bord

Oui, tu as bien vu : la seule différence entre avec effet de bord et sans, c'est la petite esperluette "&" qui traine entre int et i!!!

Il est tellement facile de ne pas remarquer cette petite esperluette que l'on ne peut pas garantir qu'elle sera systématiquement remarquée dans cent pour cent des cas (y compris quand on arrive avec la gueule de bois le lundi matin au bureau, parce qu'on a fêté la naissance du petit dernier )

Je t'ai dit, dans mon intervention précédente, que

100% des bugs trouvent leur origine dans l'interface entre la chaise et le clavier

Tu serais sans doute surpris du nombre de bugs que cette petite crolle qui ressemble à une saleté a pu occasionner ... simplement, parce que "quelqu'un" n'y avait pas prêté attention et ne s'était donc pas rendu compte que la fonction qu'il appelait ... occasionnait un effet de bord.

Avoue que c'est parfaitement idiot, comme bug, non Mais c'est "l'effet papillon" ; un papillon qui bat des ailes à New York provoque un ouragan à Tokyo Et tu peux être sur que les bug occasionnés "par cette bêtise" seront responsables de longues séances d'arrachage de cheveux

La règle est donc simple : Si tu sais faire autrement qu'en provoquant un effet de bord à l'aide des références, fais le... Cela te simplifiera la vie

Or, tant qu'il n'y a qu'une donnée à renoyer -- et, accessoirement que tu n'as aucune autre contrainte, cela va de soi), tu as un moyen "tout trouvé" pour éviter les effet de bord:

1. On transmet tous les paramètres sous forme de valeur (au lieu de les transmettre sous forme de référence),
2. on indique clairement le type de donnée qui devra être renvoyée par la fonction au compilateur
3. on utilise l'instruction return <nomDuneVariable/valeurEcriteEnDur>; pour renvoyer la valeur concernée

(Petit canaillou, tu as honteusement profité que j'écrivais ce roman pour changer le code que tu nous présente )