Discussion :

[Luc Hermitte]

Tu as lu les autres fils, plutôt récents en plus, qui posent le même genre de question ?

[Aurelien.Regat-Barrel]

- modifier / renvoyer une valeur en paramètre

et avec un pointeur ca marche pas ?

Qui se charge de la destruction ? Bien sûr que ça marche, c'est moins trivial c'est tout. Qui dit pointeur dit pointeur nul, donc des tests, plantages... Une référence ne peut être nulle.

- accéler l'appel de fonction en passant ses paramètres par référence(éviter une recopie d'objet)

ah, parce qu'en passant un pointeur ca recopie l'objet ?

Encore une fois où ais-je dit ça ?

qu'est ce que tu penses de

Code :

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

1
2
 
void test( std::string * s );

j'en pense que ceci compile:

Code :

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

1
2
 
test( 0 );

et qu'il faut se préoccuper de rajouter un & a chaque passage, complication syntaxique purement inutile car une référence fait aussi bien, et même mieux:

Code :

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

1
2
3
4
5
6
 
void test1( const std::string * s );
void test2( const std::string & s );
 
test1( "coucou" ); // marche pas
test2( "coucou" ); // ca marche, objet temporaire std::string créé et passé en paramètre

personne ne m'a encore prouvé qu'on pouvait se passer des pointeurs, c'était pourtant le but de ma question

personne ne te prouvera, les pointeurs ont leur utilité, tout comme les références.

[:Bronsky:]

personne ne m'a encore prouvé qu'on pouvait se passer des pointeurs, c'était pourtant le but de ma question

Ah bon, le but de la question était d'avoir CETTE réponse et pas une autre ?

Ben dans ce cas désolé, effectivement personne ne te donnera cette réponse, puisqu'on ne peut pas se passer des pointeurs. (pour les raisons que plusieurs personnes viennent d'expliquer)

[Nico65]

personne ne m'a encore prouvé qu'on pouvait se passer des pointeurs, c'était pourtant le but de ma question

personne ne te prouvera, les pointeurs ont leur utilité, tout comme les références.

ok... vous ennervez pas

[SKZ81]

Pour le passage d'args à une fonction, pointeurs et références sont "sémantiquement" identique (à la différence qu'on ne peut pas RE affecter une ref), syntaxiquement différent.
Dans les deux cas on parle de l'adresse en mémoire de la variable considéré, adresse stockée dans une variable locale à la fonction (en pile, juste avant les variables automatiques, on touve les arguments de la fonction appellé).
Point de vue assembleur généré c'est équivalent...

Attention : ce que je dis est faux pour un 'alias' créé dans le même bloc de code : la valeur de l'adresse est résolut à la compilation, donc au niveau assembleur, celà strictement à utiliser la variable de départ.
Mais je n'ai rencontré ce cas que dans les codes didactiques expliquant la syntaxe des références...

[:Bronsky:]

Pour le passage d'args, si tu prends un pointeur, tu peux opter pour 2 façons de faire :
- farcir ton code de "if (ptr)", le rendant moins lisible et moins performant
- décider de ne pas faire les tests en partant du principe que tu ne te trompe jamais. En cas d'audit du code, je te souhaite bonne chance si tu compte avancer cet argument.

Une référence ne pouvant être nulle, y a pas photo, pour le passage d'args c'est ça qu'il faut.

J'ajouterai qu'un pointeur, non content de pouvoir être nul, peut aussi être fou. Et ça, aucun test ne permet de le savoir. Ici encore, les références apportent une garantie.

[Luc Hermitte]

Oui et non. On peut faire n'importe quoi en déférençant un pointeur invalide pour le passer à une fonction qui attend une référence -- disons que si il y a des pointeurs à un moment ou un autre, ils peuvent continuer à être mal employés, et au fond le problème serait déplacé.

Code :

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

f(v[v.size()]);

(l'erreur ne sera pas aussi évidente dans un vrai code)

[:Bronsky:]

C'est vrai mais ta possibilité d'erreur est en tout cas localisée. Plus les portions de code utilisant les pointeurs seront rares, plus la recherche d'un bug de ce type (particulièrement coriaces et longs à localiser) sera rapide.

[Blocks]

(Remontage de topic)

Bonjour, je vois pas l’intérêt qu'a eu ce débat.
Les références sont des pointeurs plus jolis.
Les pointeurs existent en C++ pour une meilleure rétrocompatibilité avec les sources en C, et chose que personne n'a mentionné, pour manipuler la mémoire librement.

Avec un pointeur, si je fais un int, je peux afficher séparément les valeurs des 4 octets qui le composent.

La question à se poser est : "Avez vous vraiment besoin d'un accès libre à la mémoire ?" Si oui, pointeurs. Si non, références.

[oodini]

Si dans une liste de paramètres, on doit donner une valeur par défaut, on est contraint d'utiliser les pointeurs.

[Emmanuel Deloget]

Si dans une liste de paramètres, on doit donner une valeur par défaut, on est contraint d'utiliser les pointeurs.

Est-ce que tu peux expliciter ça ? Il me semblait, mais je peux me tromper, qu'on peut mettre une valeur par défaut à un const &.

[jblecanard]

Bonjour

J'ai l'impression que vous réfléchissez trop sur les références. Leur concept est extrêmement simple, et il est aisé à retenir. Il suffit de revenir à l'origine historique des références. Elles ont été conçues dans le but du passage d'arguments (à des fonctions où des opérateurs). Les pointeurs et les références ont des usages différents et font bien leur boulot chacun dans leur domaine. Le débat pointeur où référence n'a pour moi pas de sens.

Je comprend que les références puissent dérouter les codeurs qui viennent du C, mais c'est un fait : en C++, on passe les arguments par référence parce que c'est pensé pour, et puis voilà.

[jblecanard]

Est-ce que tu peux expliciter ça ? Il me semblait, mais je peux me tromper, qu'on peut mettre une valeur par défaut à un const &.

Il me semble aussi, mais ce n'est pas possible pour une référence non const. Un argument non const qui peut avoir une valeur par défaut reflète un design un peu louche...

[oodini]

Un argument non const qui peut avoir une valeur par défaut reflète un design un peu louche...

Si tu considères qu'avoir un argument optionnel est louche, on peut effectivement aller dans ton sens...

[jblecanard]

Non, j'ai bien dit un argument optionnel non const, ce qui change pas mal de choses

[oodini]

J'ai récemment codé une fonction toute bête qui devait remplir un vecteur, et éventuellement un deuxième. A déterminer au moment de l'appel.

J'ai choisi de passer en paramètres de la fonction un pointeur sur chacun des vecteurs. Si le second ne devait pas être rempli, l'appelant recourait à la fonction en ne fournissant que le premier argument. Le second avait alors comme valeur par défaut nullptr.

Et je testais la valeur de ce pointeur dans le corps de la fonction.

Je précise que les deux vecteurs se remplissent dans la même boucle, et qu'il était donc stupide de séparer ces deux "remplissages".

Comment aurais-tu fait autrement ?

[jblecanard]

Difficile de répondre sans connaître le contexte. Je suppose que j'aurais encapsulé les deux vecteurs dans un objet puisque s'ils se remplissent ensemble, il est probable qu'une sémantique soit partagée.

Tu as sans doute eu raison de t'y prendre ainsi. Toute règle a ses exceptions. Personnellement, les seules fois où j'ai dû réaliser des passages par pointeurs étaient pour faire des appels sur des librairies en C. D'autres cas existent évidemment, mais je n'ai pour l'instant jamais été forcé de faire des passages de pointeurs en argument optionnels.

Je ne suis pas un extrémiste des références non plus : rendre le code plus complexe juste pour n'utiliser que des références n'est à mon avis pas malin.

[arash]

Une référence est comme un pointeur à l'exception des différences suivantes:
1 - vous devez l'utiliser comme ref.member pas ptr->member
2 - Il doit être initialisé pour pointer vers un objet - sinon, le code ne compilera pas.
3 - Après l'initialisation, vous ne pouvez pas le faire pointer vers un autre objet.
4 - Vous ne pouvez pas prendre l'adresse d'une référence
5 - vous ne pouvez pas faire l'arithmétique avec des références

références sont indispensables pour "operator overloading"
Si vous choisissez d'utiliser une référence, assurez-vous que vous n'avez pas besoin de "NULL pointer"

[Emmanuel Deloget]

J'ai récemment codé une fonction toute bête qui devait remplir un vecteur, et éventuellement un deuxième. A déterminer au moment de l'appel.

J'ai choisi de passer en paramètres de la fonction un pointeur sur chacun des vecteurs. Si le second ne devait pas être rempli, l'appelant recourait à la fonction en ne fournissant que le premier argument. Le second avait alors comme valeur par défaut nullptr.

Et je testais la valeur de ce pointeur dans le corps de la fonction.

Je précise que les deux vecteurs se remplissent dans la même boucle, et qu'il était donc stupide de séparer ces deux "remplissages".

Comment aurais-tu fait autrement ?

Personnellement, j'aurais fait deux fonctions : une fonction à un argument, une autre à deux arguments. Comme ça, élimination des tests et je n'ai pas besoin de passer un pointeur.

[oodini]

Personnellement, j'aurais fait deux fonctions : une fonction à un argument, une autre à deux arguments. Comme ça, élimination des tests et je n'ai pas besoin de passer un pointeur.

Dans ce cas là, je n'avais plus besoin de passer par des fonctions.
L'intérêt était de factoriser les deux traitements.