Exercice pointeur en c++

Bonjour,
je suis une débutante, j'ai trouvé un exercice sur les pointeurs et j'avoue avoir beaucoup de mal à comprendre le principe :? .
quelqu'un peut-il me donner la correction de cet exercice? :

Code:

---

1 2 3 4 5

void main() { int a=1;int b= -2; int c = 0; ajouet(a,b,c); cout <<"c=" << c << "/n"; }

---

1/
donner la sortie du programme dans les cas suivants :
void ajouter(int a,int b,int c) {c= a+b ;}
void ajouter(int a,int b,int *c) {*c= a+b ;}
void ajouter(int a,int b,int &c) {c= a+b ;}

Comment s'appelle ces 3 passages de paramètres?
Merci pour votre aide :) .

Salut,

bienvenue sur ce forum. Quand tu passes un paramètre à une fonction, tu as 2 possibilités : passage par valeur (donc le paramètre n'est pas modifiable) et par référence (donc le paramètre est modifiable)

Code:

---

1 2 3 4

void ajouter(int a,int b,int c) {c= a+b ;} void ajouter(int a,int b,int *c) {*c= a+b ;} void ajouter(int a,int b,int &c) {c= a+b ;}

---

dans le 1e cas, c n'est pas modifié, dans les 2 autres cas c sera modifié.
Dans le 1e cas, c est passé par valeur, dans le 2e on a un pointeur sur c et dans le 3e on a une référence sur c

Je te laisse potasser un peu plus les pointeurs et les références. Ce sont des notions très importantes si tu veux faire du C++. Regarde aussi le mot-clé "const" qui est très utilisé avec les références.

Dernier point, ce n'est pas

Code:

---

1 2 3 4 5

void main() {   }

---

mais

Code:

---

1 2 3 4 5 6

int main() {   return 0; }

---

ou

Code:

---

1 2 3 4 5 6

int main(int nargin, char ** argc) {   return 0; }

---

Salut, et bienvenue sur le forume

Citation:

---

Envoyé par salseropom

<snip>...
ou

Code:

---

1 2 3 4 5 6

int main(int nargin, char ** argc) {   return 0; }

---

---

A vrai dire, bien que le nom des paramètres soit tout à fait libre, on utilise généralement

Code:

---

int main (int argc, char argv)

---

• argc étant l'abréviation de "argument count"
• argv etant l'abréviation de "argument values"

Ceci dit, pour compléter un peu la réponse de salseropom, je voudrais attirer ton attention sur le fait que, en C++, on préfère n'utiliser les pointeurs que lorsque l'on n'a vraiment pas le choix, car ils sont très fortement associés au phénomène de la gestion dynamique de la mémoire et à tous les problèmes que ce phénomène sous-entend.

Et, surtout, d'éviter le recours à l'opérateur "address of" afin de permettre le passage d'un pointeur à une fonction.

Les références ont en effet quelques avantages par rapport aux pointeurs, dont:

• la garantie de non nullité : un pointeur devant être nul, tu dois vérifier qu'il ne le soit pas avant d'essayer d'accéder à l'objet pointé... cette contrainte n'existe pas avec les références ;)
• le respect de la syntaxe "classique": avec les pointeurs, tu dois utiliser la fleche "->" ou explicitement dire que tu veux accéder à "ce qui est pointé par" ton pointeur (*ptr).truc, alors qu'avec les références, tu utilise exactement la même syntaxe que celle que tu utiliserais si tu avais affaire à un objet et non à une référence ( ref.truc)

Tu comprendra donc assez facilement que

Citation:

---

Et, surtout, d'éviter le recours à l'opérateur "address of" afin de permettre le passage d'un pointeur à une fonction.

---

ca se discute, l'opinion opposée etant que les références sont moins lisibles lors de l'appel de fonction.
Lorsque je tape "&variable" je vois bien que ma variable risque d'être modifiée. Lorsque je passe "variable" seulement, il faut aller voir la fonction.

Citation:

---

Envoyé par screetch

ca se discute, l'opinion opposée etant que les références sont moins lisibles lors de l'appel de fonction.
Lorsque je tape "&variable" je vois bien que ma variable risque d'être modifiée. Lorsque je passe "variable" seulement, il faut aller voir la fonction.

---

Lorsque tu tape "&variable", tu sais qu'il est possible qu'elle soit modifiée, mais, si tu n'a pas accès au code de la fonction, tu n'a aucun moyen de t'en assurer...

Lorsque tu tape "variable", tu dois, effectivement, vérifier le prototype de la fonction, mais tu n'a pas besoin d'avoir accès à son code, parce que tu as trois solutions:

1. l'argument est passé par valeur, et les modifications ne sont pas répercutées
2. l'argument est passé par référence, et les modifications seront répercutées
3. l'arguemnt est passé par référence constante et les modifications sont impossibles

Evidemment, cela nécessite de respecter la "const correctness" tout au long de ton projet :P

Hum, il y a aussi le mot const pour les pointeurs :roll:. L'avantage du passage par adresse c'est que tu es sur que ce n'est pas passer par valeur, même sans voir le prototype... Remarque, comment savoir qui faut le passer par adresse si on a pas vu le prototype oO !

Citation:

---

Envoyé par Lavock

Hum, il y a aussi le mot const pour les pointeurs :roll:. L'avantage du passage par adresse c'est que tu es sur que ce n'est pas passer par valeur, même sans voir le prototype...

---

Si ce n'est que le mot clé const prendra une signification différente selon sa position:

1. int * const représente un pointeur constant sur... un entier qui ne l'est pas
2. int const * représente un pointeur non constant sur... un entier constant
3. const int * représente lui aussi un pointeur non constant sur un entier qui constant

(1) et (2) appliquent la règle générale, alors que (3) applique la règle particulière

Alors que, lorsqu'il s'agit de référence

1. int & const sera refusé à la compilation
2. int const & représente une référence sur un objet constant (meme si, par abus de langage on parle volontiers de référence constante)
3. const int & représente lui aussi une référence sur un objet constant

(2) applique, encore, la règle générale alors que (3) applique la règle particulière

Le tout, sans compter sur le fait que le nom de la fonction devrait aussi représenter une aide efficace en vue de déterminer comment est utilisé un argument;)

Citation:

---

Remarque, comment savoir qui faut le passer par adresse si on a pas vu le prototype oO !

---

Là encore, le choix du nom de la fonction s'avère important, de manière à faire en sorte qu'il décrive "aussi bien que possible" l'objectif recherché ;)

Citation:

---

Envoyé par koala01

Si ce n'est que le mot clé const prendra une signification différente selon sa position:
[LIST=1][*]int * const représente un pointeur constant sur... un entier qui ne l'est pas

---

J'ai jamais trop su à quoi ça servait de préciser ça côté utilisateur... Après tout, le pointeur et récupérer par copie, donc constant ou pas...

Citation:

---

Envoyé par koala01

Là encore, le choix du nom de la fonction s'avère important, de manière à faire en sorte qu'il décrive "aussi bien que possible" l'objectif recherché ;)

---

Depavred generation inside : Je lis les entêtes des fonction grâce à l'auto-complétion. Plus besoin d'avoir de nom qui reflète ceci du coup :aie: !

Citation:

---

Envoyé par Lavock

J'ai jamais trop su à quoi ça servait de préciser ça côté utilisateur... Après tout, le pointeur et récupérer par copie, donc constant ou pas...

---

on peut vouloir mettre un champ const dans une classe pour interdire de le changer après l'instanciation. Un concept malhueureusement assez peu utilisé :(

Code:

---

1 2 3 4 5

class A { int const m_value; // doit être initialisé dans le constructeur et ne pourra jamais être changé int* const m_pointer; // de même, on ne pourra jamais changer ce pointeur pour un autre; mais on pourra changer ce sur quoi il pointe };

---

ce que tu dis est justifié seulement pour les variables locales ou les retours de fonctions

Code:

---

void* const alloc() // n'a pas de sens, puisqu'on va le copier de toutes facons...

---

Citation:

---

Envoyé par Lavock

Depavred generation inside : Je lis les entêtes des fonction grâce à l'auto-complétion. Plus besoin d'avoir de nom qui reflète ceci du coup :aie: !

---

j'ai oublié le pire...
c'est une très mauvaise habitude. La première documentation c'est le nom de la méthode, le nom des paramètres n'apparait plus apres.
une fonction qui prend 8 paramètres, souvent entiers ou booléens, devient illisible très vite, surtout si son nom est peu évocateur. Si en plus il y a des références, la c'est la mort.

exemple sur les références :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

bool addIfNoOverflow(int& result, int x, int y) { if((x+y) < max) { result = x+y; return true; } else { return false; } }     ... if(addIfNoOverflow(a, b, c)) // sans lire la declaration, ou est le résultat??? { }   if(addIfNoOverflow(&a, b, c)) // ici, très clair sans aller vérifier, si on passe par un pointeur { }

---

Citation:

---

Envoyé par screetch

on peut vouloir mettre un champ const dans une classe pour interdire de le changer après l'instanciation. Un concept malheureusement assez peu utilisé :(

---

A ceci près que côté utilisateur de la classe, ceci relève d'un détail d'implémentation...

Pour les noms, je suis bien d'accord... Mais rien interdit de nommer les variables dans la déclaration, histoire qu'il s'affiche à la complétion ><.

Salut,
Avec un pointeur, je me demande toujours si j'ai le droit de mettre NULL si le résultat ne m'intéresse pas. Avec une référence, je sais que je n'ai pas le droit de mettre NULL. Rien que cette différence me fait préférer les références dans la plus part des cas et les pointeurs que pour d'éventuel retour optionnel (quoique je pourrais passer par du Boost.optional) ou lorsque c'est dans la logique du framework.

Citation:

---

Envoyé par Lavock

A ceci près que côté utilisateur de la classe, ceci relève d'un détail d'implémentation...

Pour les noms, je suis bien d'accord... Mais rien interdit de nommer les variables dans la déclaration, histoire qu'il s'affiche à la complétion ><.

---

rien ne t'interdit, mais tout te pousse à ne pas le faire, du moins si tu ne veux pas donner une valeur par défaut à un argument...

D'abord, parce que cela va t'obliger à déterminer le nom de ton argument avant d'arriver à l'implémentation, et à respecter l'homogénéité entre la déclaration et l'implémentation

Ensuite, parce qu'un compilateur *risque*, s'il est bien réglé, de se plaindre qu'un argument n'est pas utilisé si ce n'est effectivement pas le cas.

Bien sur, tu me diras que, étant donné que ce n'est qu'un avertissement, on peut très bien décider de l'ignorer, mais, de manière générale, j'ai tendance à tout faire pour apporter une solution correcte à tous les avertissements que le compilateur m'envoie... Soucis du détail, quand tu nous tiens ;)

Ainsi, imaginons une hiérarchie de classe proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

/* Base est une classe instanciable...*/ class Base { public: virtual void doSomething( Type /* const &*/ t); }; class Derived : public Base() { public: virtual void doSomething( Type /* const &*/ t); }; void Base::doSomething(Type /* const &*/ t) { /* La fonction lance d'office une exception quand elle est   * invoquée depuis une instance de Base... mais c'est prévu   * comme cela ;)   */ throw MyException(); } void Derived::doSomething(Type /* const &*/ t) { /* utilise t pour faire ce qu'on attend de la fonction */ }

---

Un compilateur bien réglé se plaindra d'un

Code:

---

warning in void Base::doSomething : t is defined but never used

---

ou d'un avertissement similaire
Alors que, si tu modifie Base en

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/* Base est une classe instanciable...*/ class Base { public: virtual void doSomething( Type /* const &*/ ); }; void Base::doSomething(Type /* const &*/ ) { /* La fonction lance d'office une exception quand elle est   * invoquée depuis une instance de Base... mais c'est prévu   * comme cela ;)   */ throw MyException(); }

---

tu évites l'avertissement, et tu ne perdra donc pas de temps à te demander ce que le compilateur vient te dire: après tout, tu sais très bien que l'argument n'est pas utilisé pour base, et c'est ainsi qu'il doit en aller ;)

Pour l'homogénéité, on est d'accord, mais j'y vois aucun problème. On peut très bien faire :

Code:

---

1 2 3 4 5 6 7

class A { void truc(int nom); }; //... void A::truc(int) { }

---

mais aussi

Code:

---

1 2 3 4 5 6 7 8

class A { void truc(int = 0); }; //... void A::truc(int i) { //utilisation de i }

---

Aucun cas ci-dessus ne fournit d'avertissement sous GCC 4.4.1 en -Wall -W -pedantic -std=c++0x >< !

Citation:

---

Envoyé par Lavock

<snip>On peut très bien faire :

Code:

---

1 2 3 4 5 6 7

class A { void truc(int nom); } //... void A::truc(int) { }

---

mais aussi

Code:

---

1 2 3 4 5 6 7 8

class A { void truc(int = 0); } //... void A::truc(int i) { //utilisation de i }

---

---

je devrais vérifier, mais il me semble que le deuxième code est mal formé :P

Je dis peut être une bêtise monumentale, mais, j'ai l'impression qu'un code n'est bien formé que si l'on donne le nom de l'argument auquel on donne une valeur par défaut...

Citation:

---

Envoyé par koala01

je devrais vérifier, mais il me semble que le deuxième code est mal formé :P

---

Oui, il manque le ';' à la fin de la définition de la classe :mouarf:
En revanche, tu n'es pas obligé de nommer les variables pour leur donner une valeur par défaut.

oui c'est vrai que je n'avais pas vu cet angle la, 3DArchi. Ca m'ennuie tiens, maintenant je suis confus.

Citation:

---

Envoyé par 3DArchi

Oui, il manque le ';' à la fin de la définition de la classe :mouarf:
En revanche, tu n'es pas obligé de nommer les variables pour leur donner une valeur par défaut.

---

Voilà bien la preuve qu'il faut laisser croire les béguines, elles sont spécialistes, et payées pour :D:oops:

HS : une béguine, c'est une religieuse non ?!? Je vois pas le rapport :?

Citation:

---

Envoyé par Lavock

HS : une béguine, c'est une religieuse non ?!? Je vois pas le rapport :?

---

C'est bien une religieuse, oui...

Pour trouver le rapport, intéresse toi peut-être à la qualité la plus remarquable (hormis le célibat) des religieuses :D

Ben une béguine, ça n'as pas d'Ordre et vis même pas dans un couvent (ça peu même être mariée !), donc pas de fantasme :roll:...

Hum...Bon stop HS, j'ai compris ou tu voulait en venir >< !