Discussion :

[méphistopheles]

Bonjour.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[méphistopheles]

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 . 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

?

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

[Goten]

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

[Flob90]

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)

[méphistopheles]

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 ...)

[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 ?

[méphistopheles]

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 ?

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 )) pourquoi fairais-t'on la différence ?

[Flob90]

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)

[méphistopheles]

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.

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....

[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 ?

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[3DArchi]

Bonjour.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
struct trucmuche{};
trucmuche var;

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

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

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.

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

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

[méphistopheles]

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...

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

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 ?

Si tu parles de ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
struct trucmuche{};
trucmuche var;

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

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.

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.

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.

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 ) À ce propos, comment font-ils pour les opérateurs "->" ?


Merci

[méphistopheles]

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 ...

[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)

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).

[méphistopheles]

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

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 ) 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.

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.

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...

[Goten]

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

sous forme d'opérateur libre...

[méphistopheles]

sous forme d'opérateur libre...

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

[3DArchi]

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

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

[méphistopheles]

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 ) 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....... en suite, c'est juste une question de gout. je n'applique absolument pas ça lorsque je code..