Discussion :

[koala01]

Salut,

Pour commencer, je voudrais revenir sur ce qui a été dit :

Je suis tout à fait d'accord qu'au niveau du code binaire généré, pointeurs et référence sont du pareil au même, mais, au niveau du code C++ (et c'est ce qui nous intéresse ici ), ce sont deux choses radicalement différentes! :

D'abord parce que les pointeurs et les références présentent des possibilités différentes (le fait qu'un pointeur puisse etre nul et qu'une référence apporte une garantie de non nullité étant l'une des différences principales)

Ensuite, parce qu'un pointeur est une variable de type numérique qui représtente l'adresse à laquelle on va trouver une variable d'un type donné, alors qu'une référence est un alias de la variable.

Rajoutez à cela la capacité des références à suivre et à respecter la constance : une référence constante certifie que l'objet passé en référence ne sera pas modifié, alors qu'un pointeur constant ne garanti que le fait que l'on n'essayera pas de modifier l'adresse pointée (il faut passer un pointeur sur un objet constant ou un pointeur constant sur un objet constant pour garantir que l'ojbet ne sera pas modifié )

Il faut aussi compter sur le fait que les références permettent de créer des variables temporaires non nommées, et c'est la raison pour laquelle on ne peut fournir une valeur par défaut que dans le cas de référence constante (on créera une variable qui n'existera que pour la durée de l'exécution de la fonction appelée, il n'y a donc absolument pas lieu d'en permettre la modification )

Enfin, parce qu'Ils s'utilisent de manière radicalement différente, et pas seulement du point de vue de la syntaxe :

Imaginez une chaine C style comme exemple d'utilisation d'un pointeur. Si vous voulez réallouer un espace mémoire supplémentaire, vous devrez passer par ... un pointeur de pointeur, et vous devrez donc penser à accéder à ce qui est pointé par ce pointeur de pointeur.

De là à se retrouver à travailler avec des pointeurs de pointeurs de pointeurs (de pointeurs, de... ), il n'y a qu'un pas, et la complexité de travail suivra la même évolution

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.

Tu aurais très bien pu faire quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
9
void foo(std::vector<type> & tab)
{
    /* remplissage du tableau */
}
void foo(std::vector<type> & first, std::vector<type>& second)
{
    foo(first);
    foo(second);
}

et

1. tu te serais évité l'utilisation d'un pointeur
2. tu te serais évité des tests de non nullité sur le second argument
3. ton code aurait été parfaitement factorisé

[oodini]

En règle générale, effectivement.

Mais le code concerné est si menu que ça ne valait franchement pas le coup de faire deux fonctions (déjà, en faire une...).

[Emmanuel Deloget]

En règle générale, effectivement.

Mais le code concerné est si menu que ça ne valait franchement pas le coup de faire deux fonctions (déjà, en faire une...).

Dans ce cas précis, la factorisation t'empêche d'avoir un chemin optimal. Tu as certainement besoin de tests dans ta fonction unique, tests que tu pourrais éviter en écrivant deux fonctions. Puisque le but est d'initialiser les deux vecteurs dans la même boucle, on peut légitimement penser que les performances sont un facteur important du design.

Le changement n'est pas anodin, c'est sûr. Deux fonctions qui font un traitement similaire vont à l'encontre de la notion de non duplication du code (ça fait deux endroits à maintenir). Comme le dirait personne en particulier, "it's your call".

[oodini]

Si ça n'avait tenu qu'à moi, il n'y aurait pas eu de fonction, car il n'y a quasiment pas de redondance de code. C'est un gros algorithme. Idéalement, il eût fallu faire des blocs de code rétractables via des #pragma region.

Mais je suis dans un projet où la modularisation en fonctions est un dogme.