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]

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...

[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à.