À partir de http://www.cplusplus.com/reference/utility/pair/, nous savons qu' std::pair a deux variables membres, first et second.
Pourquoi la STL concepteurs décident d'exposer deux variables membres, first et second, au lieu de proposer un getFirst() et getSecond()?
Pour le C++03 std::pair, les fonctions d'accès à la membres ne servirait à rien.
Que de C++11 et plus tard (nous sommes maintenant à la C++14, avec C++17 à venir rapidement) std::pair est un cas spécial de l' std::tupleoù std::tuple peut avoir un nombre quelconque d'éléments. En tant que tel, il est logique d'avoir un paramétrée de lecture, il serait difficile d'inventer et de normaliser un nombre arbitraire de leurs noms. Ainsi, vous pouvez utiliser std::get également pour un std::pair.
Ainsi, les raisons pour la conception sont historiques, que le courant en std::pair ) est le résultat d'une évolution vers une plus grande généralité.
Dans d'autres nouvelles:
concernant
” Autant que je sache, il sera mieux si l'encapsulation des deux variables de membre ci-dessus et de donner un
getFirst();etgetSecond()
non, c'est de la foutaise.
C'est comme de dire que le marteau est toujours mieux, si vous êtes à la conduite dans les clous, fixation avec des vis, ou de découper un morceau de bois. Surtout dans le dernier cas, un marteau est pas juste un outil utile. Les marteaux peuvent être très utiles, mais cela ne signifie pas qu'ils sont “mieux” en général: c'est tout simplement absurde.
Les accesseurs et mutateurs sont généralement utiles si l'on pense que l'obtention ou la définition de la valeur nécessite de la logique supplémentaire (le changement de certains état interne). Cela peut ensuite être facilement ajoutés dans la méthode. Dans ce cas - std::pair ne sert qu'à fournir des données 2 valeurs. Rien de plus, rien de moins. Et donc, l'ajout de la verbosité d'un getter et setter serait inutile.
La raison en est qu'aucun invariant doit être imposée sur la structure des données, std::pair modèles à usage général conteneur pour les deux éléments. En d'autres termes, un objet de type std::pair<T, U> est supposé pour être valide pour toute éventuelle first et second élément de type T et U, respectivement. De même, les mutations ultérieures dans la valeur de ses éléments ne peuvent pas vraiment d'incidence sur la validité de l' std::pair soi.
Alex Stepanov (l'auteur de la STL) explicitement présente cette conception générale principe lors de son cours de Programmation Efficace avec les Composants, en commentant l' singleton conteneur (c'est à dire, un conteneur d'un élément).
Ainsi, bien que le principe en lui-même peut être une source de débat, c'est la raison derrière la forme d' std::pair.
Les accesseurs et mutateurs sont utiles si l'on croit que l'abstraction est justifiée, afin d'isoler les utilisateurs de choix de conception et les changements dans ces choix, maintenant ou dans l'avenir.
L'exemple typique de "maintenant", c'est que le setter/getter peut avoir de la logique de valider et/ou de calculer la valeur - par exemple, utiliser un setter pour un numéro de téléphone, au lieu d'exposer directement le champ, de sorte que vous pouvez vérifier le format; utiliser un getter pour une collection de sorte que la lecture peut fournir une vue en lecture seule de la valeur (une collection) à l'appelant.
L'canonique (si mauvais) exemple pour "les changements dans l'avenir" est - Point - devrait vous exposer x et y ou getX() et getY()? La réponse habituelle est d'utiliser des getters/setters, car à un certain moment dans l'avenir, vous souhaitez peut-être modifier la représentation interne de Cartésiennes, polaires et vous ne voulez pas que vos utilisateurs d'être touchés (ou de faire dépendent de cette décision de conception).
Dans le cas d' std::pair - c'est le but de cette classe, maintenant et à jamais représentent deux et exactement deux valeurs (de type arbitraire) directement, et d'offrir à leurs valeurs sur demande. C'est tout. Et c'est pourquoi la conception utilise directement l'accès des membres, plutôt que de passer par un getter/setter.
Il pourrait être soutenu que l' std::pair serait mieux d'avoir des fonctions d'accesseur pour accéder à ses membres! Notamment pour les cas dégénérés d' std::pair il pourrait être un avantage. Par exemple, lorsqu'au moins l'un des types est un vide, non-finale de la classe, les objets pourraient être plus petits (le vide de la base pourrait être faite d'une base, qui n'auraient pas besoin d'obtenir sa propre adresse).
À l'époque, std::pair a été inventé ces cas particuliers n'ont pas été considérés (et je ne suis pas sûr si le vide optimisation de la base a été admis dans le projet de document de travail à l'époque). À partir d'une sémantique point il n'y a pas beaucoup de raisons d'avoir des fonctions d'accesseur: clairement, les accesseurs aurait besoin de retourner un mutables de référence pour les non-const objets. En conséquence, l'accesseur de ne pas fournir toute forme d'encapsulation.
D'autre part, il [un peu] plus difficile sur l'optimiseur de voir ce qu'il se passe lors de l'accesseur fonctions sont utilisées, par exemple, parce que plus de la séquence de points sont introduits. Je ne pouvais imaginer que Meng Lee et Alexander Stepanov a même mesuré si il y a une différence (je n'ai). Même si ils n'ont pas, en fournissant l'accès aux membres directement est certainement pas plus lent que de passer par une fonction d'accès, tandis que l'inverse n'est pas nécessairement vrai.
Je n'étais pas partie de la décision et de la norme C++ n'est pas une justification, mais je suppose que c'était une décision délibérée de rendre les membres du public de données des membres.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
