Est-il préférable de faire des getters et setters inline?

public:
     inline int GetValue() const {
          return m_nValue;
     }
     inline void SetValue(int nNewValue) {
          this -> m_nValue = nNewValue;
     }

Sur Apprendre le C++, ils ont dit qu'il irait plus vite. Alors, j'ai pensé qu'il serait idéal pour une utilisation sur les getters et les setters. Mais peut-être, il ya quelques inconvénients à cela?

  • Merci à tous! Conclusion générale: ne le faites pas, le compilateur va prendre soin d'elle.
  • Il dépend. Si vous les avez dans la définition de la classe, il n'est pas nécessaire de l'inclure, car ils le sont déjà par défaut. Si vous faites la mise en œuvre dans un autre .fichier cpp, alors il est à l'éditeur de liens, ce qui peut être intelligent comme sur la célèbre plates-formes ou tout simplement un muet de l'éditeur de liens qui ne sont pas inline rien à moins de connaître les quais autant que je sache.
  • Permettez-moi d'ajouter quelques mots à la réponse que j'ai donné ci-dessous. Personnellement, je n'aime pas le désordre de ma déclaration de classe avec le code que je considère cette partie de la (technique) de la documentation. Même argument pour la définition de la méthode dans le fichier d'en-tête, mais pas aussi mauvais. Ah et enfin: Vous avez vraiment besoin getters et setters? 🙂
  • Je suis d'accord, les accesseurs et mutateurs est rarement une partie de la bonne pratique.
  • en fait, c'est surtout les poseurs qui sont d'une mauvaise pratique.
  • Une lecture peut-être pas une mauvaise pratique (bien que je serais favorable à pousser au lieu de tirer), d'autre part l'obtention de l'état de l'objet est une violation de l'encapsulation, qui est dans la plupart des cas de mauvaise pratique.
  • exposer seulement un getter n'est pas une violation de l'encapsulation, il ne vous oblige à maintenir l'accès à la donnée dans le cadre de votre interface publique. Du point de vue du client, il n'y a aucun moyen de savoir si l'objet possède la valeur ou n'a accès (éventuellement par l'intermédiaire d'un autre objet). En outre, à la suite de votre argument, une extraction des informations à partir de l'objet est une violation de encapsultion.

InformationsquelleAutor Martijn Courteaux | 2010-06-10
  1. 55

    Je n'ai pas inline rien jusqu'à ce qu'un profiler a aussi spécifiquement m'a dit que non inline entraîne un problème de performance.

    Le compilateur C++ est très intelligent et sera presque certainement automatiquement inline telle fonction simple comme ça pour vous. Et généralement, c'est plus intelligent que vous, et va faire un bien meilleur travail à la détermination de ce qui devrait ou ne devrait pas être insérée.

    Je voudrais éviter de penser à ce que à ou de ne pas en ligne et se concentrer sur la solution. L'ajout de la inline mot-clé plus tard (ce qui n'est pas une garantie de inline BTW) est très facile à faire et de lieux potentiels peuvent être trouvés facilement avec un profiler.

    • Le compilateur ne peut pas inline quelque chose si vous mettez sa mise en œuvre dans un fichier source séparé. Pas pertinents pour l'exemple présenté, mais vaut la peine de mentionner néanmoins.
    • En effet, à la fois GCC et VS offre un alignement entre les fichiers source.
    • c'est un peu vrai car à ce stade c'est en fait l'éditeur de liens, pas le compilateur.
    • Je n'ai jamais entendu parler de ça et ne peux pas imaginer comment il sera mis en œuvre. A un lien?
    • msdn.microsoft.com/en-us/library/xbf3tbeh(SV.71).aspx
    • Peut-être que l'éditeur de liens pourrait faire le travail si les deux fichiers sont dans le même projet. Mais si vous liez une pré-DLL compilée il n'y a aucun moyen pour qu'il inline tout ce qui n'est pas explicitement contenues dans les fichiers d'en-tête.
    • Correct, pour les Dll qu'il ne peut pas être intégrées à l'encontre de l'objectif d'une DLL. Il peut inline travers statiques des bibliothèques.
    • Je pense que LTCG sera inline eux
    • Bien sûr, le compilateur ne peut pas, mais le linker peut, et LTO est maintenant très répandu chose, ce qui rend sans objet le rendement hypothétique opposition à des getters/setters (même si il y a d'autres objections que nous pouvons utiliser dans de nombreuses situations!)

    InformationsquelleAutor JaredPar
  2. 29

    Si vous écrivez à l'intérieur de la définition, ils sont considérés comme inline par défaut.

    Cela signifie qu'ils seront autorisés dans plusieurs unités de compilation (depuis définitions de classe eux-mêmes apparaissent généralement dans plusieurs unités de compilation), pas qu'ils être inline.

    • Si le compilateur veut inline eux...
    • La norme C++ considère les fonctions inline si elles sont définies dans la définition de la classe, qui est presque entièrement sans rapport avec le compilateur/linker une fonction inline.
    InformationsquelleAutor AraK
  3. 16

    C'est une Mauvaise pratique dans les API de Tout changement de ces fonctions nécessite la recompilation de tous les clients.

    En général avoir des getters et setters montre des pauvres de l'abstraction, de ne pas le faire.
    Si vous êtes constamment les données brutes dans une autre classe, alors vous avez probablement besoin de ré organiser vos classes, au lieu de considérer la façon dont vous souhaitez manipuler les données à l'intérieur d'une classe et de fournir des méthodes pour le faire.

    • pourriez-vous élaborer sur la mauvaise abstraction? que voulez-vous dire exactement, et comment est-elle le reflet de cet exemple? devrait m_nValue juste être public?
    • Une classe doit être une abstraction, eh bien, quelque chose. Sa mise en œuvre ne devrait pas d'importance, et les opérations doivent avoir un sens pour ce qu'il représente. Il devrait y avoir de la classe d'invariants: les déclarations qui sont toujours vraies à propos de la classe. Les accesseurs et mutateurs exposer la mise en œuvre, presque autant que les variables publiques. Dans mon expérience, les valeurs des variables individuelles ont tendance à ne pas être significatif en termes de classe d'abstraction, de sorte que vous êtes en permettant des opérations de la classe qui ne sont pas pertinentes à son abstraction. Les accesseurs et mutateurs rend plus difficile le maintien d'invariants.
    • peut-être la valeur stockée est un int, c'est peut-être un certain type, qui est librement créé à partir d'un int et converti en int, aucune idée. la cueillette de la valeur à partir de la classe et de faire quelque chose avec elle - que faites-vous avec elle, pourquoi n'est-ce pas une caractéristique de la classe de sorte qu'un getter n'est pas nécessaire, d'essayer de minimiser le faible niveau de couplage entre les classes.
    • David Thornley dit-il tellement mieux que moi.
    • Hyper-dogmatique non-sens. Vous ne pensez pas qu'il ya un besoin pour obtenir la longueur d'une chaîne de caractères? Modifier le texte sur un bouton de l'INTERFACE utilisateur? Récupérer les coordonnées de la souris? Certes, il est possible de l'abus des getters et setters, comme il l'est pour n'importe quel motif. Mais "ne pas faire" comme une couverture en règle de l'OMI mauvais conseils.
    • J'ai l'impression qu'elle est juste généralisation d'un point de départ. Étant donné le niveau de la question est le juge approprié. J'ai l'impression que votre avoir un peu d'une réaction d'hypersensibilité moment.
    • Je pense que tout le monde est d'avoir une réaction d'hypersensibilité moment. Clairement, les conteneurs sont des accesseurs (enfin, l'équivalent via références): il est explicitement partie de leur but de se disputer particulier modifiables valeurs. Aussi clairement, la plupart des classes ne sont pas des conteneurs. Le problème avec les conseils "en général, ne pas le faire", c'est qu'il est difficile d'utiliser les conseils - pour un exemple d'un bon getter/setter, la réponse est "je l'ai dit, ne le font pas en général, ce n'est pas ne pas le faire quand c'est une bonne idée". De sorte que le conseil est exactement équivalent à, "en général, ne font que des choses qui sont une bonne idée, dans les circonstances particulières" ;-p
    • Je comprends votre point; et 1 pour l'ajout d'un "en général"..
    • Bien sûr, il ya un besoin pour obtenir la longueur d'une chaîne. C'est une opération qui a du sens pour une chaîne de caractères, et il n'exige pas que la longueur de la chaîne seront directement stockés dans la classe. Modifier le texte d'un bouton de l'INTERFACE utilisateur est peut-être un meilleur exemple, que le texte est presque certainement une variable membre, mais il est logique dans le contexte d'un bouton de l'INTERFACE utilisateur. Vous donnez des exemples d'activités qui ont du sens en fonction de la catégorie de l'abstraction, mais qui sont probablement mises en œuvre que les getters et les setters. Je ne vois pas que nous sommes en fait d'accord.
    • Peut-être que nous pouvons arriver à quelque chose de plus utile. Voici ma proposition: Ne pas concevoir dans les getters et les setters. La conception de fonctions qui sont utiles en termes de l'abstraction. Il est logique, par exemple, de parler de la coordonnée X d'un point, ou la longueur d'une chaîne. Si celles-ci s'avèrent être, essentiellement, des getters et setters, eh bien, c'est facile à mettre en œuvre.
    • Sonne bien. Les Classes qui représentent quelque chose qui a naturellement visible de l'état dans le cadre de l'interface externe, comme le "sujet" d'un message électronique ou de l'bgcolor d'un ordinateur de bureau, sont susceptibles de se retrouver avec des getters (et setters si la classe est modifiable). Il est faux de concevoir une classe par emballage de membres dans les getters et les setters comme une question de cours, juste comme beaucoup que c'est mal de faire des membres de la partie de l'interface publique comme une question de cours.

    InformationsquelleAutor Greg Domjan
  4. 10

    Points négatifs:

    1. Le compilateur est libre à vous ignorer.

    2. Tout changement de ces fonctions nécessite la recompilation de tous les clients.

    3. Un bon compilateur inline non-inline fonctions de toute façon, quand c'est approprié.

    InformationsquelleAutor Crazy Eddie
  5. 5

    Je tiens également à ajouter que si vous effectuez des millions de obtient ou définit par le cadre, c'est à peu près hors de propos, si elles sont intégrées ou non. C'est franchement pas la peine de perdre le sommeil plus de.

    Aussi, gardez à l'esprit que juste parce que vous mettez le mot 'inline' en face de votre déclaration de+définition, ne signifie pas que le compilateur inline votre code. Il utilise différentes heuristiques pour déterminer si elle fait sens, ce qui est souvent le classique échange de la vitesse et de la taille. Cependant, il est la force brute '__forceinline mot-clé, à la location dans VC++ (je ne suis pas sûr de ce qu'il est en CCG), qui piétine sur les compilateurs de fantaisie heuristiques. Je ne recommande pas du tout, et en plus une fois que vous port pour une architecture différente, ça risque d'être incorrecte.

    Essayer de mettre toutes les définitions de fonctions dans le fichier d'implémentation, et de laisser la pure déclarations pour les en-têtes (sauf si bien sûr vous êtes modèle de la métaprogrammation (STL/BOOST/etc), dans ce cas, à peu près tout est dans les en-têtes ;))

    Un des lieux classiques de gens aiment à en ligne (au moins dans les jeux vidéo, qui est d'où je suis originaire), est en mathématiques, en-têtes. La croix-point des produits, les longueurs de vecteur, d'une matrice de compensation, etc sont souvent placées dans l'en-tête, qui je pense n'est pas nécessaire. 9/10 il ne fait aucune différence de performance, et si jamais vous avez besoin de faire une boucle serrée, tels que la transformation d'un grand vecteur matrice par la matrice, vous êtes probablement mieux manuellement de faire le calcul à la volée, ou encore mieux de codage dans la plate-forme de l'assembleur.

    Oh, et un autre point, si vous vous sentez vraiment besoin d'une classe pour être plus de données que le code, pensez à utiliser la bonne vieille structure, qui n'apporte pas la OO bagages de l'abstraction avec elle, c'est tout ce qui existe. 🙂

    Désolé, je ne voulais pas aller sur beaucoup de choses, mais je pense juste qu'il aide à considérer monde réel de cas d'utilisation, et ne pas avoir trop accroché sur pédant paramètres du compilateur (faites-moi confiance, je suis là ;))

    Bonne chance.

    Shane

    • Un autre commentaire ici: si vous forcez l'in-lining, vous risquez la possibilité de faire une boucle trop gros, et après avoir éventuellement quelques problèmes de mise en cache. Les problèmes de Performance peuvent être contre-intuitif avec des Processeurs modernes. Si vous allez à la force inline, faire un test de performance avec et sans, et de garder la forcé associé uniquement si cela aide.
    InformationsquelleAutor Shane
  6. 2

    Le code compile un peu plus longtemps et vous perdez de l'encapsulation. Tout dépend de la taille du projet et de sa nature. Dans la plupart des cas, il est OK pour faire inline si ils n'ont pas une logique complexe.

    BTW, vous pouvez sauter inline si vous mettez en œuvre directement dans la définition de la classe.

    InformationsquelleAutor Paul
  7. 2

    En mettant le code dans l'en-tête, vous exposez votre classe interne fonctionnement. Les Clients peuvent voir et de faire des hypothèses sur la façon dont votre classe fonctionne. Cela peut rendre plus difficile de changer votre classe, plus tard, sans casser le code du client.

    InformationsquelleAutor Tim Rupe
  8. 1

    Je dirais que vous n'avez pas besoin de s'embêter avec ça. Lire la Section FAQ sur inline.

    InformationsquelleAutor mkluwe
  9. 1

    Pas nécessaire, commencer à avoir confiance les compilateurs, au moins pour ces optimisations!

    "Mais pas toujours"

    InformationsquelleAutor Numan
  10. 1

    Le mot-clé inline est dénuée de sens dans votre cas

    Compilateur inline votre fonction si elle peut et veut, indépendamment de mot-clé.

    Le mot-clé inline affecte de liaison et de ne pas l'in-lining. C'est un peu déroutant, mais la lire.

    Si la définition est dans une autre unité de compilation (fichier source après préprocesseur, essentiellement) que de l'appel, d'inlining ne sera possible que si l'ensemble du projet de l'optimisation et de la liaison de génération de code sont activés. Permettant il augmente considérablement les temps de lien (depuis pratiquement re-compile tout dans l'éditeur de liens), mais, évidemment, peut améliorer les performances. Vous ne savez pas si il est activé ou désactivé par défaut de GCC et VS.

    InformationsquelleAutor Gal
  11. 0

    Je dois dire que je n'ai pas la forte aversion pour cette pratique que d'autres sur ce fil semble avoir. Je suis d'accord que le gain de performance de l'in-lining est négligeable dans tous les, mais le plus largement utilisé de cas. (Et oui, je ont rencontré de tels cas dans la pratique.) Lorsque je fais ce genre de l'in-lining, je le fais pour des raisons de commodité, et en général seulement pour les one-liners comme ça. Dans la plupart de mon cas d'utilisation, de la nécessité d'éviter la recompilation sur le côté client si jamais je les changer n'est tout simplement pas fort.

    Oui, vous pouvez déposer de l' inline, comme il est implicite par le placement de la mise en œuvre.

    Aussi, je suis un peu surpris de la véhémence contre les accesseurs. Vous pouvez à peine éternuer à une classe dans tout langage OO, sans souffler un peu en bas, et ils ne sont après tout une technique valable pour résumé la mise en œuvre de l'interface, donc c'est un peu masochiste pour réclamer eux aussi mauvais OO pratique. Il est de bons conseils pour ne pas écrire de accesseurs tort et à travers, mais je vous conseille de ne pas se laisser emporter dans le zèle pour les éradiquer.

    Prendre que, puristes. 🙂

    InformationsquelleAutor Owen S.