Discussion :

[_skip]

Bonjour,

J'ai écrit un algo de clustering en C++ et je cherche à l'optimiser un minimum. Toutefois je me pose une questions concernant les getter/setter de mes classes. Ce sont en majorité de simples "return x" et "x ="

Ai-je besoin de les déclarer inline ou est-ce que ce genre de chose est automatique lorsqu'on utilise GCC avec les optimisations niveau 2 activées?

[koala01]

Salut,

Je commencerais déjà par me poser la question de l'utilité de la plupart de ces fonctions.

Si, effectivement, un accesseur est de temps en temps utile pour permettre la récupération d'une propriété, un mutateur "simple" ne me semble que rarement adapté

Ceci dit, l'inlining respecte des règles bien précises:

• Lorsque tu définis une fonction au sein même de la définition d'une classe, la fonction est réputée être implicitement déclarée inline
• Pour les autres, seules les fonctions explicitement déclarées inline seront réputées comme telles.

Si je parle de fonction réputées inline, c'est parce que le mot clé ne fait encore que demander au compilateur de les implémenter de manière inline, mais qu'il reste libre de décider de le faire ou non

Enfin, certaines options de compilation peuvent modifier la manière dont gcc va créer les fonctions inline

Tu trouvera la plupart de ces options de compilation ici

[_skip]

Merci je vais regarder cela.

Toutefois je pense que dans mon cas l'encapsulation est nécessaire pour les raisons suivantes :

- J'ai des setter qui déclenchent des mises à jour au sein de l'objet, c'est pas le cas de tous mais ça me semble un peu trash de mixer de l'accès public et du get/set au sein de mes classes.

- Je souhaite pouvoir retourner mes membres sous forme de référence constantes, (même si je n'ai pas encore résolu tous les problèmes qui vont avec ce mode de faire...)

[_skip]

Ok j'ai pu trouver la réponse à ma question là dedans.

Il semble que j'ai le choix entre utiliser les options O3 ou finline-functions, ou alors déclarer explicitement inline (je voulais éviter car j'ai l'impression que ça pollue un peu mon .h mais soit).

[koala01]

Merci je vais regarder cela.

Toutefois je pense que dans mon cas l'encapsulation est nécessaire pour les raisons suivantes :

- J'ai des setter qui déclenchent des mises à jour au sein de l'objet, c'est pas le cas de tous mais ça me semble un peu trash de mixer de l'accès public et du get/set au sein de mes classes.

En toute honnêteté, je me méfie énormément des setters purs et simples:

Si tu en viens à accepter, pour une raison ou une autre, que l'on aille modifier un membre sans vérifier la validité de la modification ou sans que la modification de ce membre n'entraine une mise à jour d'autres propriétés de l'objet, c'est sans doute qu'il n'y a aucune raison de vouloir "cacher" ce membre au "reste du monde" (et peut être qu'il est bon de se poser la question de l'utilité de ce membre dans la classe envisagée )

[CedricMocquillon]

Le seul avantage que j'y vois (pour le moment) c'est qu'étant une méthode de classe, on peut utiliser le polymorphisme dessus (dans la mère on sait que l'on veut modifier une propriété, dans une des filles ça peut correspondre à une affectation bête et méchante (mais faut bien la faire) et dans une autre à un calcul exotique et de multiples vérifications avant modification des attributs membres)

[koala01]

Le seul avantage que j'y vois (pour le moment) c'est qu'étant une méthode de classe, on peut utiliser le polymorphisme dessus (dans la mère on sait que l'on veut modifier une propriété, dans une des filles ça peut correspondre à une affectation bête et méchante (mais faut bien la faire) et dans une autre à un calcul exotique et de multiples vérifications avant modification des attributs membres)

J'ai quand même, sans m'être accordé le temps de la réflexion sur le sujet, beaucoup de mal à imaginer une telle discordance entre deux classes suffisamment proches pour avoir un ancêtre commun

De plus, j'adhère à l'idée que le simple usage de "set" dans le nom d'une fonction est généralement dangereux car trop "générique".

C'est la raison pour laquelle tu remarquera que j'utilise les termes accesseurs et mutateurs plutôt que ceux de getter et setter