[FAQ C++ ?] Passage d'un pointeur en parapètre template

Bonjour.

Récemment, en essayant de faire une classe encapsulante un peu particulière de type

Code:

---

1 2 3 4 5

template <class T> class OverClass : public T { //[...] };

---

, je me suis aperçu que ça ne marchait pas avec les pointeurs. c'est apparemment un comportement connu, mais j'ai trouvé très peu de documentation à ce sujet (bon, je ne suis pas non plus doué en recherche). De même la spécialisation pour un pointeur de type:

Code:

---

1 2	template <class T> class OverClass<T*>

---

n'a pour moi rien d'évident et me semble être un comportement particulier du système de template.

S'il est vrai que ces problèmes de types de données templates vont probablement disparaitre avec l'arrivée de types_trait (et is_pointer) et c++0x, je me demandais s'il n'aurait pas été pertinent d'avoir un article dans la FAQ à ce propos.

Je pourrais éventuellement le faire, mais je ne suis pas sûr de correctement appréhender ce concept donc j'aurais aimé avoir votre avis à ce sujet et sur les fondamentaux de cette règle auparavant.

Cordialement

Tu pourrais détailler les comportement que te dérange ? Quelque chose doit m'échapper, puisque je n'y vois que des comportements normaux prévus par la norme.

Citation:

---

Envoyé par Flob90

Tu pourrais détailler les comportement que te dérange ? Quelque chose doit m'échapper, puisque je n'y vois que des comportements normaux prévus par la norme.

---

Je ne dis pas que le comportement est anormal, mais qu'il ne suit pas celui "générique" car pour moi, A* est un type au même titre que A ou void :aie:. Mais dans le cas du pointeur, il y a un comportement particulier qui interdit d'en hériter... et pourtant, on peu tres bien imaginer hériter d'un itérateur qui est à peu près la même chose. Pour le reste, ce qui me trouble, c'est que dans le mécanisme de la spécialisation, si j'ai par exemple un pointeur sur un itérateu: ai-je le droit de spécialiser mon objet avec un

Code:

---

1 2	template <class T> class maclass<T**>

---

?

bref, le coté "exceptionel" du pointeur a tendence à me faire voir ça comme un cas particulier :?

C'est une spécialisation partielle, jvois pas ce qu'il y'a de gênant là...

La deuxième est une spécialisation partielle comme le dit Goten, c'est pas inhabituelle comme écriture. (Alp en utilise beaucoup dans un de ces articles, orienté méta-prog je crois)

Le premier c'est normal et spécifié dans la norme, la classe de base doit être un class-name, et * ou & ne peuvent faire partie d'un class-name. (même combat pour const et volatile)

Citation:

---

Envoyé par Flob90

et * ou & ne peuvent faire partie d'un class-name. (même combat pour const et volatile)

---

C'est justement pour cette "précision" que je m'étonne: à quoi est-ce dû ? existe-il une justification de cette exclusion ? comment est-ce précisé (je dois avouer que j'aimerais avoir une doc de type "référence" reproduisant la norme, mais en organisé (les drafts, ça va bien quans on les lit au fur et à mesure, mais pour trouver un truc dedans ...)

J'ai peut être mal compris mais tu te demandes pourquoi l'on ne peut pas dériver d'un pointeur ?
Quel sens pourrait-il y avoir à dériver d'un type fondamental ? Ce serait comme dériver de int ou float, ce ne sont pas des classes ou des structures, ils n'ont pas de fonctions membres, pas de données membres non plus, pas de constructeur, pas de destructeur, que reste-il à hériter ? :P

Citation:

---

Envoyé par Arzar

J'ai peut être mal compris mais tu te demandes pourquoi l'on ne peut pas dériver d'un pointeur ?
Quel sens pourrait-il y avoir à dériver d'un type fondamental ? Ce serait comme dériver de int ou float, ce ne sont pas des classes ou des structures, ils n'ont pas de fonctions membres, pas de données membres non plus, pas de constructeur, pas de destructeur, que reste-il à hériter ? :P

---

des méthode: le déréférencement, le "->" et par conséquent, toutes les méthodes du type principal ... qui lui peut être for complexe. Pour moi, un type n'est pas basique...Pour le français ça va, mais je n'aime pas les langages dont les règles on des exceptions (mais je n'ai rien contre les exeptions (mais c'est un autre débat :aie:)) pourquoi fairais-t'on la différence ?

Citation:

---

Envoyé par méphistopheles

C'est justement pour cette "précision" que je m'étonne: à quoi est-ce dû ? existe-il une justification de cette exclusion ? comment est-ce précisé (je dois avouer que j'aimerais avoir une doc de type "référence" reproduisant la norme, mais en organisé (les drafts, ça va bien quans on les lit au fur et à mesure, mais pour trouver un truc dedans ...)

---

Oo, c'est l'inverse, plus simple de chercher un truc précis dans la norme, que de la lire en entier (lire un doc technique de 1200+ pages en entier, c'est très fatiguant je trouve). Surtout que là, l'information elle est en introduction de la section 10, pas dur à trouver !
Il n'y a pas d'exception ou d'eclusion, la règle c'est qu'une classe de base doit être un class-name, c'est tout ! (et j'ai aussi du mal à voir l'interet d'hériter d'une pointeur, d'une référence où d'un objet const ou volatile)

Citation:

---

Envoyé par Flob90

Oo, c'est l'inverse, plus simple de chercher un truc précis dans la norme, que de la lire en entier (lire un doc technique de 1200+ pages en entier, c'est très fatiguant je trouve). Surtout que là, l'information elle est en introduction de la section 10, pas dur à trouver !

---

Je veux dire que c'est plus simple de suivre progressivement l'évolution de la norme en cours plutot que de chercher un truc dans ce document de 1200 pages.

Citation:

---

Envoyé par Flob90

Il n'y a pas d'exception ou d'eclusion, la règle c'est qu'une classe de base doit être un class-name, c'est tout ! (et j'ai aussi du mal à voir l'interet d'hériter d'une pointeur, d'une référence où d'un objet const ou volatile)

---

certes, mais ça me fais un peu penser à la nécéssité de préciser "struct" avant une structure dans la norme précédente. Résultat, on faisait des typedef, mais il était clair que cette "précision" ne devait pas apporter grand chose. De même, au lieu d'un pointeur, on utilisera un quelquonque itérateur ou un wrapper... il n'empèche que parfois, j'aimerais bien pouvoir générer automatiquement les déréférencements sur méthodes de types "->".
La différenciation class name / non class name a surement une raison (probablement liée aux compilateurs) mais je n'en voie pas de raison logique. Si un itérateur qui peut avoir exactement le même comportement qu'un pointeur est de type class name, la différence étant juste sémantique alors que les objets "sont" (en terme de fonvtionalité... et peut être de code machine généré) les mêmes, pourquoi les différencier ?

Bref, je pose beaucoups de questions qui semblent plus métaphysiques qu'autre-chose, mais quand ça touche les choix de la normes, c'est rare que ce soit une conversation glabre...:aie:.

J'ai l'impression que pour toi classe = type. Alors qu'une classe définit bien un type, mais qu'un type n'est pas une classe, un classe name désigne une classe. Si tu te demandes pourquoi on peut pas hériter d'une type pointeur, demandes toi aussi pourquoi on peut pas hériter d'un type de fonction. D'un point de vue POO, l'héritage représente "l'inclusion" (mal dit) d'une interface (héritage privée) ou l'extension d'une interface (héritage publique), un type (sauf les classes) n'ont pas d'interface, que veus tu hériter ?

Citation:

---

il n'empèche que parfois, j'aimerais bien pouvoir générer automatiquement les déréférencements sur méthodes de types "->".

---

Je comprends pas trop ce que tu voudrais faire. Supposons qu'on puisse hériter d'un type :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

struct A { void foo() {} }; struct B : A* { //j'explicite le constructeur pour voir comment ca serait instancier B() : A*(new A()) {} //utilisation interne de foo ? void g() { (**this).foo(); } }; //et si je veus utiliser foo ? B b; (*b).foo();

---

Je vois déjà pas le sens de ce genre d'heritage mais encore moins ou il pourrait te simplifier la vie !

Citation:

---

Envoyé par méphistopheles

Bonjour.

Récemment, en essayant de faire une classe encapsulante un peu particulière de type

Code:

---

1 2 3 4 5

template <class T> class OverClass : public T { //[...] };

---

, je me suis aperçu que ça ne marchait pas avec les pointeurs. c'est apparemment un comportement connu, mais j'ai trouvé très peu de documentation à ce sujet (bon, je ne suis pas non plus doué en recherche). De même la spécialisation pour un pointeur de type:

Code:

---

1 2	template <class T> class OverClass<T*>

---

n'a pour moi rien d'évident et me semble être un comportement particulier du système de template.

---

Plutôt qu'une spécialisation partielle, tu aurais pu utiliser la MP pour récupérer le type (sans pointeur/référence/const/volatile).

Citation:

---

Envoyé par méphistopheles

certes, mais ça me fais un peu penser à la nécéssité de préciser "struct" avant une structure dans la norme précédente.

---

Si tu parles de ça :

Code:

---

1 2	struct trucmuche{}; struct trucmuche var;

---

Ce n'est pas du C++, c'est du C. En C++ tu peux déjà avec la précédente norme écrire :

Code:

---

1 2	struct trucmuche{}; trucmuche var;

---

Citation:

---

Envoyé par méphistopheles

Résultat, on faisait des typedef, mais il était clair que cette "précision" ne devait pas apporter grand chose.

---

Ca indique que le codeur est passé de C à C++ sans avoir tout lu :mouarf:

Citation:

---

Envoyé par méphistopheles

La différenciation class name / non class name a surement une raison (probablement liée aux compilateurs) mais je n'en voie pas de raison logique.

---

TYPE et TYPE* sont deux types différents. Mais comme le dit Flob90, en C++, TYPE* n'est pas une classe

Citation:

---

Envoyé par méphistopheles

Si un itérateur qui peut avoir exactement le même comportement qu'un pointeur est de type class name, la différence étant juste sémantique alors que les objets "sont" (en terme de fonvtionalité... et peut être de code machine généré) les mêmes, pourquoi les différencier ?

---

Parce qu'un itérateur n'est pas un pointeur. Exemple : boost::counting_iterator. Aucun pointeur ou adresse cachée derrière. En revanche, les itérateurs doivent remplir un certain contrat selon leur catégorie, et dans ce contrat, il y a l'opérateur '*'. Mais ça n'en fait pas un pointeur.

Citation:

---

Envoyé par méphistopheles

c'est rare que ce soit une conversation glabre...:aie:.

---

C'est pas toujours au poil mais tant que ça n'est pas rasant :mouarf:

Citation:

---

Envoyé par Flob90

J'ai l'impression que pour toi classe = type. Alors qu'une classe définit bien un type, mais qu'un type n'est pas une classe, un classe name désigne une classe. Si tu te demandes pourquoi on peut pas hériter d'une type pointeur, demandes toi aussi pourquoi on peut pas hériter d'un type de fonction. D'un point de vue POO, l'héritage représente "l'inclusion" (mal dit) d'une interface (héritage privée) ou l'extension d'une interface (héritage publique), un type (sauf les classes) n'ont pas d'interface, que veus tu hériter ?

---

He bien, pour moi, ils en ont une...ou devrait en avoir. Définie par le compilateur certes, mais elle existe bel et bien. je peux tout à fait redéfinir un int ou un pointeur en écrivant une classe avec plein d'opérateurs...

Citation:

---

Envoyé par Flob90

Je comprends pas trop ce que tu voudrais faire. Supposons qu'on puisse hériter d'un type :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

struct A { void foo() {} }; struct B : A* { //j'explicite le constructeur pour voir comment ca serait instancier B() : A*(new A()) {} //utilisation interne de foo ? void g() { (**this).foo(); } }; //et si je veus utiliser foo ? B b; (*b).foo();

---

---

Je verrais plutot ça comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

struct A { void foo() {} }; struct B : public A* { //j'explicite le constructeur pour voir comment ca serait instancier B() : A*(NULL) {} //j'explicite aussi une autre méthode qui devrait pour moi être générée // par contre, je ne sais pas vraiment comment l'écrire vu que "-" est sensé //être un opérateur void ->foo(){A::foo();} //on pourrait par contre la surcharger en void ->foo(){if(A*) A*->foo(); else throw std::logic_error(std::string("pointeur non initialisé")); //évidemment, il faudrait fournir un autre constructeur et un opérateur de copie }; //pour utiliser B: B b(); //[...] try { b->foo(); } //etc...

---

Citation:

---

Envoyé par 3DArchi

Plutôt qu'une spécialisation partielle, tu aurais pu utiliser la MP pour récupérer le type (sans pointeur/référence/const/volatile).

---

heu la MP ? :oops:

Citation:

---

Envoyé par 3DArchi

Si tu parles de ça :

Code:

---

1 2	struct trucmuche{}; struct trucmuche var;

---

Ce n'est pas du C++, c'est du C. En C++ tu peux déjà avec la précédente norme écrire :

Code:

---

1 2	struct trucmuche{}; trucmuche var;

---

Ca indique que le codeur est passé de C à C++ sans avoir tout lu :mouarf:

---

en fait, je parlais de C, mais c'était une analogie. non que je prone la migration massive du c++ au D, mais de même qu'en C, tout le monde typedefait ses structs, en C++ il me semble que je dois étudier trops de cas particulier dans les templates (void, pointeur, référence, etc) si je veux une classe vraiment générique. Je me rapelle avoir vu une conférence sur c++0x parlant des initialisations. On devrait pouvoir faire des templates vraiment généraiques qui n'ont pas à se soucier d'autre chose que de la présences d'opérateur de copie, de constructeurs et de destructeurs de leur membres.

Citation:

---

Envoyé par 3DArchi

TYPE et TYPE* sont deux types différents. Mais comme le dit Flob90, en C++, TYPE* n'est pas une classe

---

Je ne le nie pas, c'est simplement que ça ne me semble fondé que sur des raisons historiques, pas sur des néssécités de POO.

Citation:

---

Envoyé par 3DArchi

Parce qu'un itérateur n'est pas un pointeur. Exemple : boost::counting_iterator. Aucun pointeur ou adresse cachée derrière.

---

Pas encore eu le temps de lire. j'y répondrais quand mes yeux iront mieux.

Citation:

---

Envoyé par 3DArchi

En revanche, les itérateurs doivent remplir un certain contrat selon leur catégorie, et dans ce contrat, il y a l'opérateur '*'. Mais ça n'en fait pas un pointeur.

---

et qu'est-ce qui diférencie un random-access-iterator d'un pointeur au juste ? (a part que l'un est héritable :aie:) À ce propos, comment font-ils pour les opérateurs "->" ?


Merci :)

Citation:

---

Envoyé par Flob90

Je vois déjà pas le sens de ce genre d'heritage mais encore moins ou il pourrait te simplifier la vie !

---

et un exemple concret un ! Je ne peux rien ajouter de plus ...:?

Je vois pas dans ton lien, un seul endroit ou tu essayes un héritage d'autre chose que d'une classe. (ni ou ca pourrait t'arranger)

Non, à part les classes, les autres type n'ont pas d'interface. int a ne fait qu'indiquer au compilateur que les données "référencées" (rien à voir avec les références) ie les n octets de ton int, par la variable a doivent être traité comme un entier. C'est une données brut, tu as son contrôles totale, pas d'interface. (Du moins c'est comme ca que je vois les types fondamentales et les pointeurs nues)

L'interface que tu proposes est étrange, ce que tu mets dans la classes se sont les noms des méthodes de l'interface, -> est similaire à *, je ne vois pas ce qu'il vient faire de les noms des méthodes !

Et oui, tu peus très bien recoder tout les types qui ne sont pas des classes pour en faire des classes, mais à part créer une couche supplémentaire plûtot inutile, je ne vois pas trôt l'interet (à part hériter).

Citation:

---

Envoyé par Flob90

Je vois pas dans ton lien, un seul endroit ou tu essayes un héritage d'autre chose que d'une classe. (ni ou ca pourrait t'arranger)

---

he bien je voiyais plutot ça comme un argument contre la différenciation class-name /autres. Pour l'héritage, pas d'idée par contre, je le reconnais :oops:

Citation:

---

Envoyé par Flob90

Non, à part les classes, les autres type n'ont pas d'interface. int a ne fait qu'indiquer au compilateur que les données "référencées" (rien à voir avec les références) ie les n octets de ton int, par la variable a doivent être traité comme un entier. C'est une données brut, tu as son contrôles totale, pas d'interface. (Du moins c'est comme ca que je vois les types fondamentales et les pointeurs nues)

---

et pourtant, int fournit des opérateurs (beaucoups), des casts etc... ensuite, le problème est pour moi historique: un unsigned int n'a rien a voir avec un int mais on a des types à deux mots (mais allez essayer d'appliquer le mot unsigned sur un string hein :aie:) au lieu d'un. int pourrait (selon moi devrait) être une classe sans que cela ne rajoute de code à l'execution, mais ça simplifierait la tâche du programmeur, et surtout uniformiserait les types.

Citation:

---

Envoyé par Flob90

L'interface que tu proposes est étrange, ce que tu mets dans la classes se sont les noms des méthodes de l'interface, -> est similaire à *, je ne vois pas ce qu'il vient faire de les noms des méthodes !

---

Je ne sais plus ou j'avais lu que "x->" n'a pas du tout le même effet que "(*x)."... une histoire de déréférencement directement sur la méthode alors que l'autre déréférence puis fait un acces sur la méthode, mais ça fait un bail et je n'avais pas compris pourquoi.

Citation:

---

Envoyé par Flob90

Et oui, tu peux très bien recoder tout les types qui ne sont pas des classes pour en faire des classes, mais à part créer une couche supplémentaire plûtot inutile, je ne vois pas trôt l'interet (à part hériter).

---

hériter, ce serait déjà pas mal :( ... (ça m'éviterais de devoir faire des wrapper pour pouvoir serializer). Et j'aurais tendance à dire que le code ne perdrait rien si c'était fait alors que ça pose plutot des problèmes pour une templatisation générique etc...

Citation:

---

et pourtant, int fournit des opérateurs (beaucoups), des casts etc...

---

sous forme d'opérateur libre...

Citation:

---

Envoyé par Goten

sous forme d'opérateur libre...

---

ha oui, c'est vrai, on peut aussi utiliser des fonctions globales :aie: mais j'aime pas ça :aie:

Citation:

---

Envoyé par méphistopheles

ha oui, c'est vrai, on peut aussi utiliser des fonctions globales :aie: mais j'aime pas ça :aie:

---

Pourquoi ? Il peut y avoir beaucoup de bonnes raisons d'avoir des fonctions libres en C++.

Citation:

---

Envoyé par 3DArchi

Pourquoi ? Il peut y avoir beaucoup de bonnes raisons d'avoir des fonctions libres en C++.

---

C'est vrai, et j'en utilise aussi souvent, c'est juste que dans mon monde idéal (et merveilleux :aie:) toutes les classes qui interagissent déclarent leurs opérateurs chacune de leur coté (si on a besoin d'opérateurs bilatéraux) et tout est classe et membre....:mrgreen:... en suite, c'est juste une question de gout. je n'applique absolument pas ça lorsque je code..

Salut,
F.A.Q. : J'ai pour surcharger mon opérateur la possibilité d'utiliser une fonction membre ou une fonction libre, que choisir ?

Et puis si c'est pour avoir des classes avec que des fonctions statiques, alors autant avoir des namespace et des fonction libres, non ? Par exemple, à quelle classe rajouter des fonctions comme sqrt, sort, std::copy, etc... Ce sont des fonction sans 'état'. Donc le C++ permettant l'utilisation de fonction libre + namespace, alors autant utiliser cette possibilité.

Citation:

---

Envoyé par 3DArchi

Salut,
F.A.Q. : J'ai pour surcharger mon opérateur la possibilité d'utiliser une fonction membre ou une fonction libre, que choisir ?

Et puis si c'est pour avoir des classes avec que des fonctions statiques, alors autant avoir des namespace et des fonction libres, non ? Par exemple, à quelle classe rajouter des fonctions comme sqrt, sort, std::copy, etc... Ce sont des fonction sans 'état'. Donc le C++ permettant l'utilisation de fonction libre + namespace, alors autant utiliser cette possibilité.

---

L'explication de la faq est plutot éloquente, je dois reconnaître que je n'avais pas envisagé les choses comme cela. Tant que j'y suis, existe t'il un moyen de recréer l'opérateur "->" ?

merci.

Tu le surcharges comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10

struct A { int i; const A* operator->() const { return this; } A* operator->() { return this; } // ou plutot : A* operator->() { return const_cast<A*>(static_cast<const A>(*this).operator->()); } };   A a; A b; a->i = b->i;

---

C'est un exemple, dans ce cas l'opérateur est assez inutile. Quand tu fais a->i ca fait : (a.operator->())->i .

Merci beaucoup...

Citation:

---

Envoyé par Flob90

Quand tu fais a->i ca fait : (a.operator->())->i .

---

...Comment se fait il que le compilateur appele deux opérateurs "->" (pas les mêmes certes) ? C'est un comportement défini par la norme ?

Citation:

---

Envoyé par Flob90

Code:

---

// ou plutot : A* operator->() { return const_cast<A*>(static_cast<const A>(*this).operator->()); }

---

---

pourquoi faire un cast d'un (const ?)A en const A en A * :koi: ... surtout que je ne suis pas sûr qu'on puisse caster un A en A* comme ça :s

Oui définit par la norme (j'ai regardé avant de poster, j'ai jamais eu besoin de surcharger ->), j'ai pas la section en tête, regarde dans l'index.


C'est une technique décrite par Meyers dans Effective C++. Ca permet de factoriser le code quand les version const et non-const d'une fonction font la même chose. Dans ce cas ca factorise pas grand chose c'est vraie.

Le premier cast sert à rajouter const au type de *this, ce qui permet d'appeller la version constante, le second cast est sur le retour de la fonction et permet d'enlever le const qui est maintenant en trop.

Citation:

---

Envoyé par Flob90

C'est une technique décrite par Meyers dans Effective C++. Ca permet de factoriser le code quand les version const et non-const d'une fonction font la même chose. Dans ce cas ca factorise pas grand chose c'est vraie.

---

Pour éviter la redondance des fonctions tout en gardant notre sucre syntaxique c'est ça ?

Citation:

---

Envoyé par Flob90

Le premier cast sert à rajouter const au type de *this, ce qui permet d'appeller la version constante, le second cast est sur le retour de la fonction et permet d'enlever le const qui est maintenant en trop.

---

Je comprend par contre, dans ce cas, on devrait avoir un static_cast<const A*>() à la place du static_cast<const A>() non ?:koi:

Oui c'est ca, éviter une duplication du code et garder le même comportement.

Non, this est de type T*, mais *this est de type T, donc c'est static_cast<cons T>(*this).func() ou static_cast<const T*>(this)->func()

Citation:

---

Envoyé par Flob90

Non, this est de type T*, mais *this est de type T, donc c'est static_cast<cons T>(*this).func() ou static_cast<const T*>(this)->func()

---

Ha oui, désolé, j'avais mal regardé les parenthèses.

Citation:

---

Envoyé par Flob90

j'ai jamais eu besoin de surcharger ->

---

Les enveloppes surchargent cet opérateur, boost::shared_ptr par expl.

Oui je m'en doute, mais j'ai jamais eu besoin de recoder ce genre de classes pour le moment.