[À télécharger] [Programmation générique] Classe trait pour le type de passage d'argument

Bonjour, Je vous propore un nouvel élément à utiliser : [Programmation générique] Classe trait pour le type de passage d'argument



Cette fonction permet de choisir automatiquement le meilleur moyen pour le passage d'argument. Elle est tirée de l'article d'Alp Mestan sur les classes de traits et de politiques.



Qu'en pensez-vous ?

Juste une question, y a t-il un avantage (d'un point de vue performance) lorsqu'il s'agit d'un int de le passer par copie plutôt que par référence constante ? N'est-ce pas la même taille ?

Citation:

---

Envoyé par NoIdea

Juste une question, y a t-il un avantage (d'un point de vue performance) lorsqu'il s'agit d'un int de le passer par copie plutôt que par référence constante ? N'est-ce pas la même taille ?

---

Les références et les pointeurs ont une taille hardware égale à la taille du mot natif. La taille d'un int est décorélée de la taille de mot native. Donc non, ce n'est pas toujours la même taille (en particulier en 64 bits, ou la taille d'une référence est 64 bits tandis que l'int est resté à 32 bits sur la plupart des plateformes).

Ceci dit, passer un int en référence constante (ou toute autre donnée dont la taille est égale ou inférieure à celle du mot natif) n'a pas vraiment de sens. En termes de performance, le gain (s'il y a, et j'en doute) est négligeable.

Si je comprend bien, tu dis que cette classe de politique est uniquement didactique et n'est pas utilisée dans un cas réel ?

Non, il a juste dit que la taille d'un int n'est pas lié à la taille "natif" du système contrairement à celle d'un pointeur (d'un référence). Et que, pour les int mais aussi pour d'autre type, si la taille est inférieure à celle d'un pointeur le passage par référence ne serait pas nécessairement un gain. Et c'est exactement ce choix que permet de faire cet outil.

Ne serait-il pas mieux de comparer sizeof(T) avec sizeof(void*) plutôt que 8 ?

Citation:

---

Envoyé par NoIdea

Si je comprend bien, tu dis que cette classe de politique est uniquement didactique et n'est pas utilisée dans un cas réel ?

---

Bien sur que si, regarde boost::call_traits

Citation:

---

Non, il a juste dit que la taille d'un int n'est pas lié à la taille "natif" du système contrairement à celle d'un pointeur (d'un référence).

---

Il me semblait pourtant que les processeurs 64 bits préféraient les int de taille 64. En tout cas, pour les char, c'est évident.

Citation:

---

Et que, pour les int mais aussi pour d'autre type, si la taille est inférieure à celle d'un pointeur le passage par référence ne serait pas nécessairement un gain.

---

Cela je l'avais compris car toute référence est pointeur caché. Cependant, bien que ce ne soit pas "nécessairement un gain", il se peut que cela ne change rien du tout. De plus, même si le pointeur à pour taille 8 octets et le int 4 octets, le gain en performance est négligeable d'après ce que j'ai compris de ceci :

Citation:

---

En termes de performance, le gain (s'il y a, et j'en doute) est négligeable.

---

A moins que tu veuilles dire que c'est la référence constante qui n'apporte aucun gain.

Citation:

---

Ne serait-il pas mieux de comparer sizeof(T) avec sizeof(void*) plutôt que 8 ?

---

Cela me paraitrait plus cohérent.

Donc, je redemande, dans le cas de la copie, on peut gagner jusqu'à 7 octets sur les processeurs habituels. Est-ce que cela change quelque chose au performances ?
Le compilateur n'est-il pas déjà capable d'effectuer ce genre d'optimisation ?
N'est-ce pas alourdir le temps de compilation pour pas grand chose ?
Est-ce que la copie permet au compilateur de mieux optimiser (ce qui me semble être la raison qui justifie le plus ce type de politique) ?

Bien sur, je ne dis pas que cette classe désavantage un programme, je dis juste qu'il me semble qu'elle n'apporte pas de gain majeur. Ais-je tord ?

Citation:

---

Bien sur que si, regarde boost::call_traits

---

Je vais regarder voir s'il donne la raison pour laquelle il faut l'utiliser.



Concernant, toutes ces histoires de copies et de passage par référence, peut-il y avoir un gain en déclarant la variable globale (pas de copie je crois) ? Bien sur, ce serait une optimisation du compilateur pas de moi (et je n'ai aucune idée de comment marche les variables globales).

ne faudrait-il pas en plus vérifier que le type est copie-constructible et sinon le passer par référence constante?

Citation:

---

Envoyé par NoIdea

Si je comprend bien, tu dis que cette classe de politique est uniquement didactique et n'est pas utilisée dans un cas réel ?

---

Non, elle a une réelle utilité.

Par exemple, on aurait pu réécrire std::vector<X>::push_back() ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <class T> class vector { public: // il faudrait ajouter ConstParamType sur le modèle de ParamType void push_back(typename Calltraits<T>::ConstParamType value) { ... } };

---

(pour info, je rappelle que le prototype donnée par C++98 est push_back(T); même pas push_back(T& const)).

T n'est pas toujours un type de base ; ça peut être absolument n'importe quoi.

Citation:

---

Envoyé par NoIdea

Il me semblait pourtant que les processeurs 64 bits préféraient les int de taille 64. En tout cas, pour les char, c'est évident.

---

Plus exactement, ils font ce qu'ils veulent. Mais il y a tellement de code écrit qui définissent "typedef unsigned int uint32" que les vendeurs de compilateurs ont bien souvent décidé de laisser les int sur 32 bits. les long font généralement 64 bits (sur une architecture 64 bits, s'entend).

Citation:

---

Envoyé par NoIdea

Cela je l'avais compris car toute référence est pointeur caché. Cependant, bien que ce ne soit pas "nécessairement un gain", il se peut que cela ne change rien du tout. De plus, même si le pointeur à pour taille 8 octets et le int 4 octets, le gain en performance est négligeable d'après ce que j'ai compris de ceci :

---

Il peut y avoir un gain infinitésimal, parce que le microprocesseur est optimisé pour lire des mots de 64 bits (en 64 bits, toujours). Du coup, lire un entier de 32 bits lui demande plus d'opérations microcodées. Ceci-dit, on parle de ce qui se passe dans le microcode, donc d'une fraction de l'horloge externe du microprocesseur. Il y a peu de chance pour que ça ait une répercussion à l'extérieur de celui-ci.

Citation:

---

Envoyé par NoIdea

A moins que tu veuilles dire que c'est la référence constante qui n'apporte aucun gain.

---

C'est ce que j'ai dit :)

Citation:

---

Envoyé par NoIdea

Donc, je redemande, dans le cas de la copie, on peut gagner jusqu'à 7 octets sur les processeurs habituels. Est-ce que cela change quelque chose au performances ?

---

Même réponse.

Citation:

---

Envoyé par NoIdea

Le compilateur n'est-il pas déjà capable d'effectuer ce genre d'optimisation ?
N'est-ce pas alourdir le temps de compilation pour pas grand chose ?

---

Non, hélas. Le compilateur a l'obligation de faire ce qu'on lui dit de faire. Il a peu de latitude pour modifier le code (il ne peut le faire que si le code modifié se comporte exactement comme l'original).

Citation:

---

Envoyé par NoIdea

Est-ce que la copie permet au compilateur de mieux optimiser (ce qui me semble être la raison qui justifie le plus ce type de politique) ?

---

C'est un débat intéressant : le compilateur peut faire des élisions de code en cas de copie d'objets lourds, notamment s'ils ne sont pas modifiés. Sur le code suivant, un compilateur intelligent n'appellera le constructeur de la classe que s'il lui fait initialiser le paramètre à partir d'une valeur qui n'est pas du type du paramètre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

template <class T> T identify(T t) { return t; }   struct X { ... (beaucoup de données) void do() { ... } };   int main() { X x; identity(x).do(); // aucune copie, grâce aux // différentes optimisations du compilateur. }

---

Le problème est que ce comportement n'est pas défini par le standard (ne pas comprendre que le standard le rend indéfini ; juste qu'il n'en parle pas, et du coup, bien que n'étant pas contraire au standard, il n'est pas obligatoire pour un vendeur de compilateur de l'implémenter).

Citation:

---

Envoyé par NoIdea

Bien sur, je ne dis pas que cette classe désavantage un programme, je dis juste qu'il me semble qu'elle n'apporte pas de gain majeur. Ais-je tord ?

---

Oui, parce qu'on parle de tous les types imaginables, pas seulement les types de base.

Citation:

---

Envoyé par NoIdea

Je vais regarder voir s'il donne la raison pour laquelle il faut l'utiliser.

---

Ne t'inquiète pas, de telles raisons existent :)

Citation:

---

Envoyé par NoIdea

Concernant, toutes ces histoires de copies et de passage par référence, peut-il y avoir un gain en déclarant la variable globale (pas de copie je crois) ? Bien sur, ce serait une optimisation du compilateur pas de moi (et je n'ai aucune idée de comment marche les variables globales).

---

Si tu souhaites passer par des variables globales, tu te trouves dans un autre problème : n'importe qui peut les modifier et tu sacrifie la réentrance (pas possible d'écrire une fonction récursive, pas possible d'écrire une fonction appelable depuis plusieurs threads,...).

Citation:

---

Le problème est que ce comportement n'est pas défini par le standard (ne pas comprendre que le standard le rend indéfini ; juste qu'il n'en parle pas, et du coup, bien que n'étant pas contraire au standard, il n'est pas obligatoire pour un vendeur de compilateur de l'implémenter).

---

Tu veux rire? La copy-elision est définie par le standard hein!

Citation:

---

Envoyé par Goten

Tu veux rire? La copy-elision est définie par le standard hein!

---

Effectivement. Mea culpa. Et pour référence, parce que j'ai eu du mal à trouver : C++98, 12.8 [class.copy] §15.

Citation:

---

Non, hélas. Le compilateur a l'obligation de faire ce qu'on lui dit de faire. Il a peu de latitude pour modifier le code (il ne peut le faire que si le code modifié se comporte exactement comme l'original).

---

Mais ce serait le cas non ?

Citation:

---

Oui, parce qu'on parle de tous les types imaginables, pas seulement les types de base.

---

Mais presque tout sizeof(classe ou structure créée par l'utilisateur) > sizeof(void*) ?

De plus,

Citation:

---

ne faudrait-il pas en plus vérifier que le type est copie-constructible et sinon le passer par référence constante?

---

Citation:

---

Ne t'inquiète pas, de telles raisons existent

---

Je me répète, mais dans le meilleur des cas, sa ne faits gagner que 7 octets ? n'est-ce pas un gain ridicule dans la plupart des cas ?

Citation:

---

Si tu souhaites passer par des variables globales, tu te trouves dans un autre problème : n'importe qui peut les modifier et tu sacrifie la réentrance (pas possible d'écrire une fonction récursive, pas possible d'écrire une fonction appelable depuis plusieurs threads,...).

---

Ce n'est pas moi qui le souhaite, ce serait une potentielle optimisation du compilateur. A t-il le droit de faire cela ?


Dernières questions :

-Quand ne faut-il pas utiliser cette classe pour le passage par référence par conséquent ?

-Cette classe peut-elle avoir un impacte significatif sur le temps de compilation si elle est utilisée partout ?

- Tu pourrais, à l'extrème, l'utiliser à chaque fois, ca t'éviterais d'avoir à réflechir (dans le cas ou un passage par référence peut convenir). Cependant l'interet n'est pas là, l'objectif c'est d'augmenter la généricité du code, si tu codes un conteneur ou un algo générique par exemple, tu ne sais pas nécessairement quel est la taille des types, donc une telle classe pourra avoir un interet dans ce cas.

- Il faudrait tester, mais étant donné la facon dont est fait la STL, s tu l'utilise uniquement pour augmenter la généricité de ton code, je ne pense pas que ca ralentisse beaucoup plus la compilation que le temps qu'il faut lorsque tu utilises la STL (et si tu utilises ailleurs des outils avec des grosses dose de template alors ca doit être négligeable)

Pour les cas de copy-elision, le standard définie ce que le compilateur peut faire, mais celui-ci a le choix de le faire ou non. Il est d'ailleurs interessant de regarder les différents choix que l'on peut faire pour implémenter une fonction en tirant profit de ces opérations, le sujet est traité sur C++Next en introduction de la move semantique.

Citation:

---

Tu pourrais, à l'extrème, l'utiliser à chaque fois, ca t'éviterais d'avoir à réflechir (dans le cas ou un passage par référence peut convenir). Cependant l'interet n'est pas là, l'objectif c'est d'augmenter la généricité du code, si tu codes un conteneur ou un algo générique par exemple, tu ne sais pas nécessairement quel est la taille des types, donc une telle classe pourra avoir un interet dans ce cas.

---

En effet, cependant, voici tous les problèmes liés à un conteneur utilisant cette classe (au lieu de tout passer par référence constante) :

-Il faut que le type (on le nomme T) soit copy-constructible.
-Il faut que sizeof(T) indique réellement la taille allouée pour la copie :
Supposons que T=Matrix avec Matrix :

Code:

---

1 2 3 4 5

class Matrix { float * data; //Plein de fonctions. };

---

La copie de Matrix va faire un new, et pourtant, sizeof(Matrix)<=8.

-Un gain de performance négligeable.

Donc, si je somme les avantages :
-Permet la copie elision.
Si je somme les désavantages :
-Peut ne pas marcher.
-Peut ralentir énormément l'exécution (grosse matrice).

Citation:

---

- Il faudrait tester, mais étant donné la facon dont est fait la STL, s tu l'utilise uniquement pour augmenter la généricité de ton code, je ne pense pas que ca ralentisse beaucoup plus la compilation que le temps qu'il faut lorsque tu utilises la STL (et si tu utilises ailleurs des outils avec des grosses dose de template alors ca doit être négligeable)

---

Ok.

Juste un point qui me semble ne pas avoir été cité jusqu'à présent :
Réaliser une copie peut être plus performant, car le compilateur peut alors savoir qu'il n'y a pas d'aliasing sur la donnée, et donc mieux optimiser.