Discussion :

[mouchT8]

Bonjour,

Voilà pour ceux qui m'ont deja vu ici ces derniers jours, je suis passé à mon bouquin de C++!

Bref!

Devoir 1 tout est ok !!

Mais pour ce qui est de mon devoir 2, j'ai un probleme assez ennuyeux.
Voici mon code tout d'abord:

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
#include<iostream.h>
#include<stdio.h>
#include<stdlib.h>
 
using namespace std;
class point 
{ 
int x,y; 
public: 
point(int abs = 0,int ord = 2){x=abs;y=ord;}// constructeur 
int coincide(point *); 
}; 
 
int point::coincide(point *adpt) 
{if ((adpt->x == x) && (adpt->y == y)) return(1);
else return(0);
} 
 
void main() {
int test1,test2; 
 
point a,b(1),c(0,2); 
test1 = a.coincide(&b); 
test2 = b.coincide(&a); 
cout<<"a et b:"<<test1<<" ou "<<test2<<"\n"; 
test1 = a.coincide(&c); 
test2 = c.coincide(&a); 
cout<<"a et c:"<<test1<<" ou "<<test2<<"\n"; 
getch() ;
}

Ce n'est pas le code en réalité qui pose problème car avec mes autres exercices c'est la même erreur qui revient à chaque fois !
La voici:

Erreur 1 fatal error C1083: Impossible d'ouvrir le fichier include*: 'iostream.h'*: No such file or directory

Quelqu'un peut m'aider??

[Lucien63]

Et comme cela ça marche ?

Code :

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

#include <iostream>

sinon il faut regarder si le fichier est bien present et s'il est accessibles dans les paths de ton compilateur.

[loicounet]

déjà un conseil:
un seul return par fonction...

ensuite, relit mieux tes exemples de cours:
t'oublies de préciser private/protected/public
le type de retour de tes fonctions
la déclaration de la classe dans un HPP, la définition dans le CPP...

si tu veux compiler en c++, prend les entêtes standards genre :

Code :

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

#include <iostream>

voila déjà ca

[mouchT8]

OK !!

Merci pour vos conseils à tous les deux!

Ca marche ainsi: <iostream> !

A bientot !!

[Aurelien.Regat-Barrel]

Lis un peu la FAQ
http://cpp.developpez.com/faq/cpp/?p...le#SL_iostream

[koala01]

Salut,

Je sais que je suis ch .. avec cela, mais tu devrais prendre l'habitude d'indenter correctement ton code, afin d'en faciliter la (re)lecture, entre autre, en permettant de repérer plus facilement les groupes d'instructions

Je me doute que, s'agissant de "devoirs", tu n'a surement pas l'intention de revenir sur le code que tu écris une fois qu'ils auront été remis, mais, dans la pratique, il apparait qu'un code est bien plus souvent lu qu'il n'est écrit/compilé (en plus... pense un peu à ton "pôôôvre prof" qui doit corriger ton code )

Le C++ fourmille de raccourcis qui, bien que ne changeant (le plus souvent) rien à l'exécutable final, permettent de gagner quelques (dixièmes de) secondes à l'écriture... mais qui rendent la (re)lecture bien plus compliquée.

Inversément, il faut favoir que, si tu place un retour à la ligne, un espace ou un caractère de tabulation là où ils sont autorisés, (en gros: entre deux identifiants), cela ne changera également rien à l'exécutable, mais facilitera grandement la relecture... le tout au prix de la perte de quelques (dizièmes de) seconde.

Il est réellement très utile de considérer ces quelques (dizièmes de) seconde que tu choisi (ou non) de "perdre" comme un "investissement" pour l'avenir:

Ton code qui te parait si clair au moment où tu l'écrit, en ayant bien en tête ce que tu fais, te paraitra forcément plus nébuleux quand il s'agira de "replonger dedans" plus tard, en ne sachant - le plus souvent - plus quel était le but ni la logique de la manœuvre.

Le seul fait de pouvoir repérer facilement les différents groupes d'instructions et les structures qui les entourent (tests, boucles, ...) te fera gagner un temps considérable dans la "réappropriation" de ton code

De plus, la C++ dispose d'un type booléen (bool), qui permet de repésenter les valeurs "vrai" (true) et "faux" (false)... Ce type serait idéal comme valeur de retour de la valeur coincide .

Le code de cette fonction pourrait donc se transformer efficacement en

Code :

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

1
2
3
4
bool Point::coincide(Point* adpt)
{
    return (adpt->x == x && adpt->y == y);
}

[ram-0000]

Et même encore plus facile à lire (je pense) en rajoutant les const et le fait que adpt est une référence

Code :

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

1
2
3
4
5
6
7
8
9
10
bool Point::coincide(const Point & adpt) const
{
    if(adpt.x != x)
        return false;

    if(adpt.y != y)
        return false;

    return true;
}

Avantages de cette écriture (de mon point de vue)
1/ c'est plus facile à lire (pas besoin de se rappeler les priorités des opérateurs (que je ne me rappelle jamais d'ailleurs )
2/ c'est plus facile à debugger, si on trace avec le debugger, on voit bien quelle partie du test (x ou y) fait que la fonction retourne false.

Inconvénients de cette écriture (toujours de mon point de vue)
1/ plusieurs return dans la même fonction. Les puristes vont crier mais sur une fonction de cette taille est ce que c'est un problème ?
2/ plus lent à exécuter, je n'en suis même pas sûr, maintenant, les optimiseurs font du bon boulot.

[mouchT8]

Merci pour ces conseils précieux :o)

C'est vrai que parfois la re-lecture ça n'est pas du gâteau !

[koala01]

Et même encore plus facile à lire (je pense) en rajoutant les const et le fait que adpt est une référence

Code :

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

1
2
3
4
5
6
7
8
9
10
bool Point::coincide(const Point & adpt) const
{
    if(adpt.x != x)
        return false;

    if(adpt.y != y)
        return false;

    return true;
}

Les références et la constante sont effectivement préférables, mais je respectais le prototype d'origine

Avantages de cette écriture (de mon poit de vue)
1/ c'est plus facile à lire (pas besoin de se rappeler les priorités des opérateurs (que je ne me rappelle jamais d'ailleurs )

Disons que, dans le cas présent, le problème ne se pose que peu: les (in)égalités étant de toutes manières évaluées en premier lieu...

Quant aux priorités des opérateurs logiques, il "suffit" de se rappeler que, en algèbre booléenne, ET est représenté par . ou * et OU est représenté par +...

Dés lors, A ET B ou C sera évalué sous la forme de (a ET b ) ou C

En outre, il reste toujours la possibilité de rajouter des parenthèses en cas de doute

2/ c'est plus facile à debugger, si on trace avec le debugger, on voit bien quelle partie du test (x ou y) fait que la fonction retourne false.

Avec un bon système de débuggage, tu peux vérifier les valeurs testées, et donc déterminer tout aussi facilement quelle partie provoque le renvoi de false

Inconvénients de cette écriture (toujours de mon point de vue)
1/ plusieurs return dans la même fonction. Les puristes vont crier mais sur une fonction de cette taille est ce que c'est un problème ?

Bah, tu sais, le SISE est sans doute le concept pour lequel on s'accommode le mieux en cas de non respect...

Cependant, ma fainéantise naturelle m'incite quand même à éviter autant que possible les lignes de codes inutiles (pour autant que le code reste compréhensible, s'entend )... et, du coup, je préfère quand même la forme que je donnais au code

2/ plus lent à exécuter, je n'en suis même pas sûr, maintenant, les optimiseurs font du bon boulot.

Sur ce point, il faudrait effectuer des bench

[Jean-Marc.Bourguet]

Code :

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

1
2
3
4
5
6
7
8
9
10
bool Point::coincide(const Point & adpt) const
{
    if(adpt.x != x)
        return false;

    if(adpt.y != y)
        return false;

    return true;
}

Code :

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

1
2
3
4
bool Point::coincide(const Point & adpt) const
{
    return adpt.x == x && adpt.y == y;
}

Je lis la première comme une fonction qui retourne true mais vérifie d'abord des préconditions (l'égalité de deux membres), retournant false si elles ne sont pas remplies.

La seconde est une fonction qui tester l'égalité de deux membres.

Je pourrais écrire les deux, mais si on considère le nom de la fonction, il est clair que la seconde méthode est la bonne. La première serait normale dans le cas d'un stub qui attend d'être complèté ou un cas dégénéré d'un membre virtuel.