Dois-je préférer des pointeurs ou des références dans les données des membres?

Voici un exemple simplifié pour illustrer la question:

class A {};

class B
{
    B(A& a) : a(a) {}
    A& a;
};

class C
{
    C() : b(a) {} 
    A a;
    B b; 
};

Donc B est responsable de la mise à jour d'une partie de C. J'ai fait passer le code à travers lint et il s'est plaint du membre de référence: lint # 1725 . Cela parle de prendre soin de la copie et des affectations par défaut, ce qui est assez juste, mais la copie et l'affectation par défaut sont également mauvaises avec les pointeurs, donc il n'y a que peu d'avantages.

J'essaie toujours d'utiliser des références là où je peux, car les pointeurs nus introduisent une incertitude quant à savoir qui est responsable de la suppression de ce pointeur. Je préfère incorporer des objets par valeur, mais si j'ai besoin d'un pointeur, j'utilise auto_ptr dans les données membres de la classe qui possède le pointeur, et je passe l'objet comme référence.

Je n'utiliserais généralement un pointeur dans les données des membres que lorsque le pointeur pourrait être nul ou changer. Y a-t-il d'autres raisons de préférer les pointeurs aux références pour les membres de données?

Est-il vrai de dire qu'un objet contenant une référence ne doit pas être assignable, puisqu'une référence ne doit pas être modifiée une fois initialisée?

Évitez les membres de référence, car ils restreignent ce que l'implémentation d'une classe peut faire (y compris, comme vous le mentionnez, empêcher l'implémentation d'un opérateur d'affectation) et n'apportent aucun avantage à ce que la classe peut fournir.

Exemples de problèmes:

• vous êtes obligé d'initialiser la référence dans la liste d'initialisation de chaque constructeur: il n'y a aucun moyen de factoriser cette initialisation dans une autre fonction ( jusqu'à C ++ 0x, de toute façon modifier: C ++ a maintenant des constructeurs délégués )
• la référence ne peut pas être rebondie ou être nulle. Cela peut être un avantage, mais si le code doit changer pour permettre la reliure ou pour que le membre soit nul, toutes les utilisations du membre doivent changer
• contrairement aux membres pointeurs, les références ne peuvent pas être facilement remplacées par des pointeurs intelligents ou des itérateurs, car la refactorisation peut nécessiter
• Chaque fois qu'une référence est utilisée, elle ressemble au type valeur ( .opérateur, etc.), mais se comporte comme un pointeur (peut pendre) - par exemple, Google Style Guide le décourage

Ma propre règle de base:

• Utilisez un membre de référence lorsque vous voulez que la vie de votre objet dépende de la vie d'autres objets : c'est une façon explicite de dire que vous ne permettez pas à l'objet d'être vivant sans une instance valide d'une autre classe - à cause de non affectation et l'obligation d'obtenir l'initialisation des références via le constructeur. C'est un bon moyen de concevoir votre classe sans rien supposer que son instance soit membre ou non d'une autre classe. Vous supposez seulement que leur vie est directement liée à d'autres instances. Il vous permet de modifier ultérieurement la façon dont vous utilisez votre instance de classe (avec new, en tant qu'instance locale, en tant que membre de classe, généré par un pool de mémoire dans un gestionnaire, etc.)
• Utilisez un pointeur dans les autres cas : lorsque vous souhaitez que le membre soit modifié ultérieurement, utilisez un pointeur ou un pointeur const pour être sûr de ne lire que l'instance pointée. Si ce type est censé être copiable, vous ne pouvez pas utiliser de références de toute façon. Parfois, vous devez également initialiser le membre après un appel de fonction spéciale (init () par exemple) et vous n'avez tout simplement pas d'autre choix que d'utiliser un pointeur. MAIS: utilisez des assertions dans toutes vos fonctions membres pour détecter rapidement le mauvais état du pointeur!
• Dans les cas où vous souhaitez que la durée de vie de l'objet dépende de la durée de vie d' un objet externe, et que vous avez également besoin que ce type soit copiable, utilisez des membres de pointeur mais un argument de référence dans le constructeur De cette façon, vous indiquez lors de la construction que la durée de vie de cet objet dépend sur la durée de vie de l'argument MAIS l'implémentation utilise des pointeurs pour être toujours copiable. Tant que ces membres ne sont modifiés que par copie et que votre type n'a pas de constructeur par défaut, le type doit remplir les deux objectifs.

Les objets devraient rarement permettre d'assigner et d'autres choses comme la comparaison. Si vous considérez un modèle d'entreprise avec des objets tels que «Service», «Employé», «Directeur», il est difficile d'imaginer un cas où un employé sera affecté à un autre.

Ainsi, pour les objets métier, il est très utile de décrire les relations un-à-un et un-à-plusieurs comme des références et non des pointeurs.

Et il est probablement correct de décrire la relation un ou zéro comme un pointeur.

Donc pas de facteur «nous ne pouvons pas attribuer».
Beaucoup de programmeurs s'habituent simplement aux pointeurs et c'est pourquoi ils trouveront n'importe quel argument pour éviter l'utilisation de référence.

Avoir un pointeur en tant que membre vous forcera, vous ou un membre de votre équipe, à vérifier le pointeur encore et encore avant utilisation, avec un commentaire "juste au cas où". Si un pointeur peut être nul, le pointeur est probablement utilisé comme une sorte d'indicateur, ce qui est mauvais, car chaque objet doit jouer son propre rôle.

Utilisez des références lorsque vous le pouvez et des pointeurs lorsque vous le devez.

Dans quelques cas importants, la cessibilité n'est tout simplement pas nécessaire. Ce sont souvent des wrappers d'algorithmes légers qui facilitent le calcul sans quitter la portée. Ces objets sont des candidats de premier ordre pour les membres de référence, car vous pouvez être sûr qu'ils détiennent toujours une référence valide et n'ont jamais besoin d'être copiés.

Dans de tels cas, assurez-vous de rendre l'opérateur d'affectation (et souvent aussi le constructeur de copie) non utilisable (en héritant boost::noncopyableou en les déclarant privé).

Cependant, comme l'utilisateur pts l'a déjà commenté, il n'en va pas de même pour la plupart des autres objets. Ici, l'utilisation de membres de référence peut être un énorme problème et doit généralement être évitée.

Comme tout le monde semble donner des règles générales, j'en proposerai deux:

• N'utilisez jamais, jamais de références d'utilisation en tant que membres de la classe. Je ne l'ai jamais fait dans mon propre code (sauf pour me prouver que j'avais raison dans cette règle) et je ne peux pas imaginer un cas où je le ferais. La sémantique est trop confuse, et ce n'est vraiment pas pour cela que les références ont été conçues.

• Toujours, toujours, utilisez des références lors du passage de paramètres aux fonctions, sauf pour les types de base, ou lorsque l'algorithme nécessite une copie.

Ces règles sont simples et m'ont bien servi. Je laisse faire des règles sur l'utilisation des pointeurs intelligents (mais s'il vous plaît, pas auto_ptr) en tant que membres de la classe aux autres.

Oui à: Est-il vrai de dire qu'un objet contenant une référence ne doit pas être assignable, puisqu'une référence ne doit pas être modifiée une fois initialisée?

Mes règles de base pour les membres de données:

• n'utilisez jamais de référence, car cela empêche l'affectation
• si votre classe est responsable de la suppression, utilisez scoped_ptr de boost (qui est plus sûr qu'un auto_ptr)
• sinon, utilisez un pointeur ou un pointeur const

Je n'utiliserais généralement un pointeur dans les données des membres que lorsque le pointeur pourrait être nul ou changer. Y a-t-il d'autres raisons de préférer les pointeurs aux références pour les membres de données?

Oui. Lisibilité de votre code. Un pointeur rend plus évident que le membre est une référence (ironiquement :)), et non un objet contenu, car lorsque vous l'utilisez, vous devez le dé-référencer. Je sais que certaines personnes pensent que c'est démodé, mais je pense toujours que cela évite simplement la confusion et les erreurs.

Je déconseille aux membres de données de référence parce que vous ne savez jamais qui va dériver de votre classe et ce qu'ils pourraient vouloir faire. Ils peuvent ne pas vouloir utiliser l'objet référencé, mais étant une référence, vous les avez forcés à fournir un objet valide. Je me suis suffisamment fait cela pour arrêter d'utiliser des membres de données de référence.

Si je comprends bien la question ...

Référence en tant que paramètre de fonction au lieu de pointeur: comme vous l'avez souligné, un pointeur n'indique pas clairement à qui appartient le nettoyage / l'initialisation du pointeur. Préférez un point partagé lorsque vous voulez un pointeur, c'est une partie de C ++ 11, et un low_ptr lorsque la validité des données n'est pas garantie pendant toute la durée de vie de la classe acceptant les données pointées. également une partie de C ++ 11. L'utilisation d'une référence comme paramètre de fonction garantit que la référence n'est pas nulle. Vous devez subvertir les fonctionnalités du langage pour contourner cela, et nous ne nous soucions pas des codeurs de canon lâches.

Référence une variable membre: comme ci-dessus en ce qui concerne la validité des données. Cela garantit que les données pointées, puis référencées, sont valides.

Le déplacement de la responsabilité de la validité de variable vers un point antérieur du code nettoie non seulement le code ultérieur (la classe A dans votre exemple), mais le rend également clair pour la personne qui utilise.

Dans votre exemple, qui est un peu déroutant (j'essaierais vraiment de trouver une implémentation plus claire), le A utilisé par B est garanti pour la durée de vie du B, puisque B est membre de A, donc une référence le renforce et est (peut-être) plus clair.

Et juste au cas où (ce qui est peu probable car cela n'aurait aucun sens dans le contexte de vos codes), une autre alternative, utiliser un paramètre A non référencé et non pointeur, copierait A et rendrait le paradigme inutile - je ne pensez vraiment pas que vous entendez cela comme une alternative.

En outre, cela garantit également que vous ne pouvez pas modifier les données référencées, où un pointeur peut être modifié. Un pointeur const ne fonctionnerait que si le pointeur référencé / vers les données n'était pas modifiable.

Les pointeurs sont utiles s'il n'est pas garanti que le paramètre A pour B soit défini ou s'il peut être réaffecté. Et parfois, un pointeur faible est tout simplement trop détaillé pour l'implémentation, et un bon nombre de personnes ne savent pas ce qu'est un low_ptr ou ne les aiment tout simplement pas.

Déchirez cette réponse, s'il vous plaît :)