Virtualiser une fonction template

Bonjour, j'utilise une classe dans un projet de prog où il y a une méthode que j'aimerai bien virtualiser car je t'utilise avec une classe fille.

Mais le problème c'est que cette méthode utilise un template:

Code:

---

template<typename T> T to();

---

Et j'ai essayé ça:

Code:

---

template<typename T> virtual T to();

---

Mais j'ai le message " error: templates may not be 'virtual' "

Donc quand j'appel la méthode avec un objet fille, la méthode mère est appelée :cry:

Une solution svp? Merci d'avance :ccool:

Bonjour,

Une fonction template ne peut être virtuelle (ca pose quelques problèmes techniques).

Ne peux tu pas exporter le paramètre template au sein de la classe ? Tu utilises cette fonction template membre sur le même objet avec plusieurs paramètres différents ?

Il est difficile de te donner une solution alternative sans savoir exactement pourquoi tu as ce besoin (il peut-être compréhensible ceci dit) ? Peux tu préciser le contexte et le pourquoi de ce besoin, ie ton design actuel et son objectif ?

Citation:

---

Envoyé par Flob90

Bonjour,

Une fonction template ne peut être virtuelle (ca pose quelques problèmes techniques).

Ne peux tu pas exporter le paramètre template au sein de la classe ? Tu utilises cette fonction template membre sur le même objet avec plusieurs paramètres différents ?

Il est difficile de te donner une solution alternative sans savoir exactement pourquoi tu as ce besoin (il peut-être compréhensible ceci dit) ? Peux tu préciser le contexte et le pourquoi de ce besoin, ie ton design actuel et son objectif ?

---

Alors en gros, la classe mère s'appelle "Variable" et les classe filles "Char" "Int" "Double" etc

Et j'aimerai par exemple convertir un tableau de Variable (contenant des "Char" "Int" "Double" etc ) en un seul type donc je fais:

for (bla bla bla)
monTableau[i]->to<Int>();

Pour convertir tout le tableau en Int.

J'espère avoir été clair dans mes explications :oops:

tu ne voudrais pas imiter le principe de boost::variant par hasard ?

Citation:

---

Envoyé par mitkl

tu ne voudrais pas imiter le principe de boost::variant par hasard ?

---

Pas vraiment, mais je connaissais pas et je trouve ça très intéressant merci :ccool:

Salut ;)

Quel est ton but lorsque tu déclares plusieurs classes Int, Double etc ... héritant de Variable ?

Edit : en fait en relisant ton post je me suis aperçu que cela revenait exactement à ce qu'avait dit @mitkl, c'est à dire à boost::variant :mrgreen:
Je crois que j'avais aussi testé ce genre de chose avant qu'on me dise que cela ne servait à rien de réinventer la roue même si c'est vrai que ça peut être assez intéressant ;)

Donc désolé mais je crois que je ne peux rien t'apporter de plus :aie:

Citation:

---

Envoyé par Lintel-oo

Salut ;)

Quel est ton but lorsque tu déclares plusieurs classes Int, Double etc ... héritant de Variable ?

Edit : en fait en relisant ton post je me suis aperçu que cela revenait exactement à ce qu'avait dit @mitkl, c'est à dire à boost::variant :mrgreen:
Je crois que j'avais aussi testé ce genre de chose avant qu'on me dise que cela ne servait à rien de réinventer la roue même si c'est vrai que ça peut être assez intéressant ;)

Donc désolé mais je crois que je ne peux rien t'apporter de plus :aie:

---

C'est pas grave, je crois que je vais devoir surcharger à fond la méthode to()

Bon finalement je pense avoir trouvé la solution:

Une fonction amie avec la classe Variable et un nouvel attribut qui renseigne sur le type de variable:

Variable.h:

Code:

---

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

class Variable { /* bla bla bla */     // Attributs public: char typeVar; // Type de la variable (exemple: 6 pour Int)     template<typename T> friend T to(Variable& v);   /* bla bla bla */   };

---

Cast.cpp: (fichier où se trouve la fonction amie)

Code:

---

1 2 3 4 5 6 7

using namespace std;   template<typename T2> T2 to(Variable& v){ return Variable(); }

---

Bon j'ai encore rien mis dedans, mais c'est juste que j'ai une erreur lors de la compilation (pourtant je me suis inspiré de http://cpp.developpez.com/faq/cpp/?page=templates)


Cast.cpp|7|error: redefinition of 'template<class T2> T2 to(Variable&)'|
Cast.cpp|7|error: 'template<class T> T to(Variable&)' previously declared here|

Où se situe l'erreur?

Bonjour,

les fonctions template ne peuvent pas être définies dans un .cpp, elles doivent être écrites dans un fichier inclus (généralement dans le .h directement, ou dans un fichier quelconque .inl, .tpl, .hxx ...)

Citation:

---

Envoyé par Bousk

Bonjour,

les fonctions template ne peuvent pas être définies dans un .cpp, elles doivent être écrites dans un fichier inclus (généralement dans le .h directement, ou dans un fichier quelconque .inl, .tpl, .hxx ...)

---

Oui désolé j'avais oublié :roll:

Merci à tous, sujet (presque ) résolu :ccool:

:salut:

J'ai l'impression que tu essaies de résoudre un problème de conception à coup de solutions techniques...
Ta classe Variable ressemble beaucoup à un god object. A éviter.
Ce que tu souhaites faire, c'est a priori un variant (un type qui peut contenir n'importe quoi). Tu peux également regarder du côté de boost.any. Mais c'est une forme de void* (tout comme boost.variant) et donc à éviter aussi.

Citation:

---

Et j'aimerai par exemple convertir un tableau de Variable (contenant des "Char" "Int" "Double" etc ) en un seul type donc je fais:

for (bla bla bla)
monTableau[i]->to<Int>();

Pour convertir tout le tableau en Int.

---

Si je comprend bien, tu veux convertir le tableau d'un type vers un autre ?

Code:

---

1 2 3

monTableau; // de type double blabla monTableau; // de type int

---

On est d'accord qu'il faut probablement ré-allouer le tableau si les types ont des sizeof différents ? (et même si c'est pas le cas, faire la conversion sur la même adresse mémoire est casse-gueule). En gros cela revient à faire :

Code:

---

1 2 3

monTableau; monTableau2 = monTableau.to<Int>(); monTableau = monTableau2;

---

J'ai l'impression que ce que tu souhaites faire, c'est un typage faible, comme on trouve dans d'autres langages ? Si c'est la cas, c'est pas forcement une bonne idée, tu perds tout ce qui fait la force du typage fort du C++

Tu peux préciser tes besoins ?

PS : quand je dis "éviter", cela ne veut pas dire qu'il faut pas utiliser ces approches. Cela veut dire que cela ne doit pas être la solution par défaut, mais la solution en dernier recours, quand toutes les autres approches ont été rejetées après réflexion

Citation:

---

Envoyé par gbdivers

Si je comprend bien, tu veux convertir le tableau d'un type vers un autre ?

Code:

---

1 2 3

monTableau; // de type double blabla monTableau; // de type int

---

On est d'accord qu'il faut probablement ré-allouer le tableau si les types ont des sizeof différents ? (et même si c'est pas le cas, faire la conversion sur la même adresse mémoire est casse-gueule). En gros cela revient à faire :

Code:

---

1 2 3

monTableau; monTableau2 = monTableau.to<Int>(); monTableau = monTableau2;

---

---

Oula non c'est pas exactement ça, non je voulais dire que j'ai un tableau de pointeurs vers des objets de type "Variable" (donc qui peut contenir des Int, Double, Char, etc (vu que c'est des classe qui dérivent de Variable) ) et par exemple pouvoir faire en gros ce genre de chose:

Code:

---

1 2 3 4 5 6 7

// Declaration du tableau de Variable* (nommé t[] )   // Declaration du tableau Int[100] (nommé t2[] )   for (int i=0; i<100;i++) t2[i] = t[i]->to<Int>();

---

to() est une fonction qui est censée caster n'importe quel type vers n'importe quel autre type (avec des exceptions et tout et tout)

Tout ça pour en fait un projet de 2ème année en DUT info, on cherche à faire un langage de prog ultra simple (une fonctionnalité de ce dernier est d'être vachement souple sur les types) donc là je code l'interpréteur (qui donne de TRÈS bons résultats jusqu'à maintenant)

Mais je ne peux pas utilisé de boost variant car ce langage utilise aussi des variables non typées (qui seront des boost variant) mais pour l'instant on en est au variable typées (pour optimisé le code pour éviter les conversions, même si justement là on bosse sur les conversions pour être vraiment souple)


Donc en gros le langage contient:

- Des variables non typées (boost:variant)

- Des variables typées pour optimiser le code et limiter les conversions de type (qui pourront être quand même converti pour + de souplesse), codée par une classe mère "Variable" dont héritent des classes fille comme Int, Char, SInt, Bool, etc...)

Ca a déjà été dit, mais là tu es en train de recoder boost::variant (ou presque) et la fonction libre get qui va avec (sauf que toi elle est membre). Si en plus tu as le droit d'utiliser boost et que tu vas l'utiliser ensuite, je vois vraiment pas l'intérêt (autre que pédagogique) de le recoder ...

Pour un interpréteur, AMA, il y a deux approches concernant les types :

• L'ensemble des types est fixé, et dans ce cas créer un type C++ par type du langage (en utilisant au besoin directement les types primitif (*)) et utiliser une structure contenant le nom de la variable et un variant sur l'ensemble des types est une solution.
• Il y a un ensemble de type défini par le langage et un moyen d'en rajouter d'autre, dans ce cas l'idée est la même sauf que le variant doit avoir un type de plus. Ce dernier type, probablement une classe, doit pouvoir permettre de caractériser entièrement un type et l'état d'une variable de ce type (à voir pour séparer clairement les deux).

Comment comptes-tu utiliser un variant pour réaliser des variables non typées ? Personnelement, un système de variable non typée je vois ca comme des couples de chaines de caractères (une pour le nom et une pour les données). Alors qu'un variant (any) je verrais plutôt ca dans le cadre d'un typage dynamique.

(*) A quoi bon coder une classe Int si le type natif du C++ int convient ?

Citation:

---

Envoyé par Flob90

Ca a déjà été dit, mais là tu es en train de recoder boost::variant (ou presque) et la fonction libre get qui va avec (sauf que toi elle est membre). Si en plus tu as le droit d'utiliser boost et que tu vas l'utiliser ensuite, je vois vraiment pas l'intérêt (autre que pédagogique) de le recoder ...

Pour un interpréteur, AMA, il y a deux approches concernant les types :

• L'ensemble des types est fixé, et dans ce cas créer un type C++ par type du langage (en utilisant au besoin directement les types primitif (*)) et utiliser une structure contenant le nom de la variable et un variant sur l'ensemble des types est une solution.
• Il y a un ensemble de type défini par le langage et un moyen d'en rajouter d'autre, dans ce cas l'idée est la même sauf que le variant doit avoir un type de plus. Ce dernier type, probablement une classe, doit pouvoir permettre de caractériser entièrement un type et l'état d'une variable de ce type (à voir pour séparer clairement les deux).

Comment comptes-tu utiliser un variant pour réaliser des variables non typées ? Personnelement, un système de variable non typée je vois ca comme des couples de chaines de caractères (une pour le nom et une pour les données). Alors qu'un variant (any) je verrais plutôt ca dans le cadre d'un typage dynamique.

(*) A quoi bon coder une classe Int si le type natif du C++ int convient ?

---

Je recréer boost::varriant car j'ai besoin d'ajouter des trucs comme un compteur de références pour CHAQUE variables pour le ramasse miette, un entier pour renseigner si cette variable est constante ou non et sa portée dans le code.
Et que pour gérer la mémoire j'utilise une classe (MemoryKernel) qui utilise un tableau de Variable* (memory[]) dont l'indice représente l'adresse de la mémoire.

Donc par exemple si j’écris un programme:

$i = 1

Après compilation on me dira que la variable d'adresse 0 (donc dans memory[0]) vaut 1.

Et aussi parce que boost::varriant peut contenir que 10 types max (or j'ai besoin de bien + de types)

A la place de recoder boost::variant (*) et d'y intégrer un compteur et d'autre "truc", tu pourrais chercher à les rendre non intruisif. Typiquement en passant par une capsule intermédiaire entre les types et ceux du variant. Ca serait surment bien plus flexible (SRP).

boost::variant peut contenir au moins 10 types, si tu as besoin de plus il y a une macro pour spécifier le nombre minimal qu'il doit gérer. Tu as combien de types en tout ?

(*) D'ailleurs même en la recodant, je pense que la séparation serait bien mieux.

Citation:

---

Envoyé par Flob90

A la place de recoder boost::variant (*) et d'y intégrer un compteur et d'autre "truc", tu pourrais chercher à les rendre non intruisif. Typiquement en passant par une capsule intermédiaire entre les types et ceux du variant. Ca serait surment bien plus flexible (SRP).

boost::variant peut contenir au moins 10 types, si tu as besoin de plus il y a une macro pour spécifier le nombre minimal qu'il doit gérer. Tu as combien de types en tout ?

(*) D'ailleurs même en la recodant, je pense que la séparation serait bien mieux.

---

Oula, genre 50.

Mais je fais la différence entre Char* Char et Char[] dans la gestion des types

Et pourquoi tu fais pas un simple composite ?

Code:

---

1 2 3 4 5 6

class Variable { boost::variant var; unsigned int nbRef; // ... };

---

Parce que vouloir refaire un boost::variant pour y ajouter 3 conneries.. c'est une bête composition :roll:

Citation:

---

Envoyé par Bousk

Et pourquoi tu fais pas un simple composite ?

Code:

---

1 2 3 4 5 6

class Variable { boost::variant var; unsigned int nbRef; // ... };

---

Parce que vouloir refaire un boost::variant pour y ajouter 3 conneries.. c'est une bête composition :roll:

---

Ce ne serait pas + simple de faire une classe qui hérite de boost::variant?

Citation:

---

Envoyé par Nurza

Ce ne serait pas + simple de faire une classe qui hérite de boost::variant?

---

Je ne crois pas que boost::variant soit prévu pour en hériter publiquement. Donc il vaut mieux privilégier une composition (pas sûr que l’héritage privé soit plus approprié).

Citation:

---

Envoyé par white_tentacle

Je ne crois pas que boost::variant soit prévu pour en hériter publiquement. Donc il vaut mieux privilégier une composition (pas sûr que l’héritage privé soit plus approprié).

---

Et pourtant ça économiserait quelques octets par variable.

J'avais aussi penser faire une classe template Variable

avec une spécialisation pour tous les types que je veux utiliser. On pourra donc faire un new Variable<int>, vous en pensez quoi? (ça pourrait éviter l'héritage et aussi la composition inutile)

PS: je ne cherche pas à avoir un code facile à coder/comprendre, je cherche à avoir un interpréteur de code compilé performant avec le moins de gaspillage de mémoire possible.

oui enfin, pour ajouter un compteur de référence...

Citation:

---

PS: je ne cherche pas à avoir un code facile à coder/comprendre, je cherche à avoir un interpréteur de code compilé performant avec le moins de gaspillage de mémoire possible.

---

j'ai toujours plus été partisan du "d'abord on fait un truc qui marche puis on l'optimise"

Citation:

---

Envoyé par mitkl

oui enfin, pour ajouter un compteur de référence...




j'ai toujours plus été partisan du "d'abord on fait un truc qui marche puis on l'optimise"

---

Ne t'en fais pas, il fonctionne (même si je n'ai implémenté que Bool, et Int)

L'origine de ce topic c'est que je cherche un moyen efficace (et économisant des lignes de codes) pour caster ces variables.

EDIT: Je n'ai pas envie de faire 50% du projet et qu'on me dise "maintenant il faut optimiser, alors on va re-écrire toute cette partie"

J'ai juste l'impression que tu tombes dans le piège de l'optimisation prématurée.
Ce qui n'est jamais une bonne idée.

Citation:

---

Envoyé par Nurza

EDIT: Je n'ai pas envie de faire 50% du projet et qu'on me dise "maintenant il faut optimiser, alors on va re-écrire toute cette partie"

---

C'est la raison même de tous les principes de conception objet dont on parle régulièrement (OCP, SRP, LSP, etc.)

Écrire un design parfait qui répond à tous les besoins, présent et futur, même quand les besoins changent (ce qui est toujours le cas), qui est optimisé dans tous les sens, n'est pas possible. La solution est donc très simple : écrire un design qui est conçu pour être évolutif (ie accepter facilement les changements), robuste (ie tolérant au changement)

Mon conseil : prend les principes un par un (voir Valider et corriger une architecture objet, première et seconde partie) et vérifie que chaque ligne de code, chaque fonction, chaque classe, respectent ces principes

Citation:

---

Envoyé par Nurza

Et pourtant ça économiserait quelques octets par variable.

---

Qu’est-ce que tu penses économiser en faisant un héritage plutôt qu’une composition ?

Une indirection, peut-être (quoi que dans bien des cas le compilo doit pouvoir l’inliner), mais des octets ??? 8O

Citation:

---

Envoyé par Bousk

J'ai juste l'impression que tu tombes dans le piège de l'optimisation prématurée.
Ce qui n'est jamais une bonne idée.

---

J'en suis pas à mon premier projet, loin de là, et au final je ne dirait pas que c'est de l'optimisation prématurée mais plutôt la bonne habitude de se dire "on va faire en sorte que ça marche du premier coup, ou du moins on va essayé"
Ce n'est pas possible évidemment de faire tout bien du premier coup, mais j'ai l'habitude de faire toujours au mieux pour éviter de perdre du temps par la suite.

Citation:

---

Envoyé par gbdivers

C'est la raison même de tous les principes de conception objet dont on parle régulièrement (OCP, SRP, LSP, etc.)

Écrire un design parfait qui répond à tous les besoins, présent et futur, même quand les besoins changent (ce qui est toujours le cas), qui est optimisé dans tous les sens, n'est pas possible. La solution est donc très simple : écrire un design qui est conçu pour être évolutif (ie accepter facilement les changements), robuste (ie tolérant au changement)

Mon conseil : prend les principes un par un (voir Valider et corriger une architecture objet, première et seconde partie) et vérifie que chaque ligne de code, chaque fonction, chaque classe, respectent ces principes

---

C'est ce que je me force à faire (voir ce que je viens de dire à Bousk) j'essaie toujours de faire au mieux mais en commençant au moins par une bonne base.

Citation:

---

Envoyé par white_tentacle

Qu’est-ce que tu penses économiser en faisant un héritage plutôt qu’une composition ?

Une indirection, peut-être (quoi que dans bien des cas le compilo doit pouvoir l’inliner), mais des octets ??? 8O

---

Code:

---

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

#include <iostream> #include "boost/variant.hpp"   using namespace std;   int main (){   typedef struct s2{   int i;   } s3;   typedef struct s1{   boost::variant< bool,char,int,double,float,unsigned char, unsigned int> b;   } s4;   cout << sizeof(s3) << endl; // 4 cout << sizeof(s4) << endl; // 16   return 0; }

---

Je me trompe? ( Ce qui est possible en effet :roll: )

EDIT: J'en déduis d'ailleurs que boost:varriant doit fonctionner avec des "union" ou un truc équivalent, or ça me gène d'avoir des variables de au moins 16 octets.

Citation:

---

Envoyé par Nurza

Code:

---

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

#include <iostream> #include "boost/variant.hpp"   using namespace std;   int main (){   typedef struct s2{   int i;   } s3;   typedef struct s1{   boost::variant< bool,char,int,double,float,unsigned char, unsigned int> b;   } s4;   cout << sizeof(s3) << endl; // 4 cout << sizeof(s4) << endl; // 16   return 0; }

---

Je me trompe? ( Ce qui est possible en effet :roll: )

EDIT: J'en déduis d'ailleurs que boost:varriant doit fonctionner avec des "union" ou un truc équivalent, or ça me gène d'avoir des variables de au moins 16 octets.

---

Déjà, tu compares la taille d’une structure contenant un double (du moins, pouvant le contenir) à celle d’une structure ne contenant qu’un int. Fatalement, la première fait au moins 8 là où la deuxième ne fait que 4.

Ensuite, boost::variant stocke le type réel de l’objet stocké. Compte donc logiquement au moins 1 octets pour ça. Pour les 7 derniers, je soupçonne l’alignement sur une plateforme 64 bits, mais c’est à vérifier, j’ai peut-être oublié quelque chose.

Enfin, je pensais (mais là c’est moi qui ai dû mal comprendre) que tu disais qu’un héritage était plus léger en mémoire qu’une composition, d’où mon étonnement (c’est le cas uniquement si on hérite d’une structure ne contenant aucune donnée membre).

Citation:

---

Envoyé par white_tentacle

Déjà, tu compares la taille d’une structure contenant un double (du moins, pouvant le contenir) à celle d’une structure ne contenant qu’un int. Fatalement, la première fait au moins 8 là où la deuxième ne fait que 4.

---

Oui c'est pour schématiser l'idée:
- d'un côté plusieurs types de variables. (ici int)
- de l'autre un seul type de variable.

Et c'est censé démontrer que l'utilisation de boost::varriant est gourmande en mémoire.

Citation:

---

Envoyé par white_tentacle

Enfin, je pensais (mais là c’est moi qui ai dû mal comprendre) que tu disais qu’un héritage était plus léger en mémoire qu’une composition, d’où mon étonnement (c’est le cas uniquement si on hérite d’une structure ne contenant aucune donnée membre).

---

J'ai dis ça où?

Oui mais au final c'est l'idée que je viens de proposer: faire une seul classe Variable pouvant prendre des template <int> <char> <bool>

Citation:

---

Envoyé par Nurza

Oui c'est pour schématiser l'idée:
- d'un côté plusieurs types de variables. (ici int)
- de l'autre un seul type de variable.

Et c'est censé démontrer que l'utilisation de boost::varriant est gourmande en mémoire.

---

Tu as zappé toute la hiérarchie dans ta structure, non*? N’oublie pas qu’elle induit un coût aussi, puisqu’il te faut un destructeur virtuel. Pas sûr qu’au final, ça te coûte moins que 16, surtout sur du 64 bits (pour cause de pointeur à 8 et d’alignement).

Enfin, je pense que tu te trompes de combat : si tu veux optimiser, mieux vaut jouer sur l’allocateur.

Citation:

---

Envoyé par Flob90

Comment comptes-tu utiliser un variant pour réaliser des variables non typées ?

---

J'aimerais bien connaitre la réponse à cette question. Personnelement je ne vois vraiment pas la problématique à laquelle répond un variant dans un système non typé. Du coup l'intérêt même d'envisager variant me laisse dubitatif.

En ce qui concerne l'optimisation d'un système type boost::variant (*), http://www.boost.org/doc/libs/1_50_0...gn.never-empty peut te donner une idée de la galère dans laquelle tu t'engages.

(*) Que ce soit ton système perso ou boost::variant, si ils répondent à la même problématique, alors les problèmes d'implémentation rencontrés risquent de se rejoindre.

Citation:

---

Envoyé par Flob90

J'aimerais bien connaitre la réponse à cette question. Personnelement je ne vois vraiment pas la problématique à laquelle répond un variant dans un système non typé. Du coup l'intérêt même d'envisager variant me laisse dubitatif.

En ce qui concerne l'optimisation d'un système type boost::variant (*), http://www.boost.org/doc/libs/1_50_0...gn.never-empty peut te donner une idée de la galère dans laquelle tu t'engages.

(*) Que ce soit ton système perso ou boost::variant, si ils répondent à la même problématique, alors les problèmes d'implémentation rencontrés risquent de se rejoindre.

---

Oui un variant<string (pour à peu près tout), [d'autre truc*]>

* Par exemple un tableau, un pointeur, etc

Le string contient en fait la plupart des éléments comme les nombres, chaînes de caractères, etc... qui seront à chaque utilisation convertit vers le type demandé.

Citation:

---

Envoyé par Nurza

Oui un variant<string (pour à peu près tout), [d'autre truc*]>

* Par exemple un tableau, un pointeur, etc

Le string contient en fait la plupart des éléments comme les nombres, chaînes de caractères, etc... qui seront à chaque utilisation convertit vers le type demandé.

---

Là pour le coup tu vas tuer tes perfs. Si tu veux être efficace, stocke les valeurs dans leur type natif !

Citation:

---

Envoyé par white_tentacle

Là pour le coup tu vas tuer tes perfs. Si tu veux être efficace, stocke les valeurs dans leur type natif !

---

J'ai pas compris là par contre.

la conversion string -> autre type est encore plus coûteuse que ce que tu essaies d'optimiser. bref, ça sert à rien
Pour ton histoire de taille, dans tous les cas, tu dois garder l'information du type réel quelque part pour faire du type faible. Tu auras obligatoirement ce coût, que tu utilises un variant ou ton type home made

Citation:

---

Envoyé par gbdivers

la conversion string -> autre type est encore plus coûteuse que ce que tu essaies d'optimiser. bref, ça sert à rien

---

Comment peut on alors représenter un typage dynamique faible comme en php?

1. en php, les perfs ont s'assoit un peu dessus
2. typage faible = variable qui peut prendre n'importe quel type (avec la liste des types connue à la compilation). C'est ce que fait boost variant
3. je comprend pas ce que tu souhaites ajouter à boost variant (si le problème de limite de nombre de type, je t'ai déjà parlé de boost any)
4.

Citation:

---

Mais je fais la différence entre Char* Char et Char[] dans la gestion des types

---

Et tu vas gérer aussi les char**, les char*[], les char***, etc ?
Il vaut mieux gérer les types de base + les modificateurs de type (*, [], const, static, mutable ? volatile ?)

Citation:

---

Envoyé par gbdivers

1. en php, les perfs ont s'assoit un peu dessus
2. typage faible = variable qui peut prendre n'importe quel type (avec la liste des types connue à la compilation). C'est ce que fait boost variant
3. je comprend pas ce que tu souhaites ajouter à boost variant (si le problème de limite de nombre de type, je t'ai déjà parlé de boost any)
4.

Et tu vas gérer aussi les char**, les char*[], les char***, etc ?
Il vaut mieux gérer les types de base + les modificateurs de type (*, [], const, static, mutable ? volatile ?)

---

Pour les tab[][] je considère que c'est des tab[] de tab[]

Sinon voila ce que ça pourrait donner si j'adopte boost::any :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

#include <iostream> #include "boost/any.hpp"   using namespace std;   enum type : unsigned char {_i_int,_i_uint,_i_char,_i_uchar};   class Variable { public: boost::any var; type t; template<typename T> Variable(T n){ var=n; if(typeid(n)==typeid(int)){ cout << "int!" << endl; t=_i_int; } else if(typeid(n)==typeid(unsigned int)){ cout << "unsigned int!" << endl; t=_i_uint; } else if(typeid(n)==typeid(char)){ cout << "char!" << endl; t=_i_char; } else if(typeid(n)==typeid(unsigned char)){ cout << "unsigned char!" << endl; t=_i_uchar; } else { cout << "? ? ?" << endl; } } };   int main (){   new Variable((char)5); new Variable((unsigned char)5); new Variable((int)5); new Variable((unsigned int)5); new Variable((bool)5);   cout << endl << "size Variable =\t"<<sizeof(Variable) << endl; cout << "size b::any =\t"<<sizeof(boost::any) << endl; cout << "size type =\t"<<sizeof(type) << endl;   return 0; }

---

Voila ce que ça donne avec GCC:

Citation:

---

char!
unsigned char!
int!
unsigned int!
? ? ?

size Variable = 8
size b::any = 4
size type = 1

---

Pourquoi une Variable consomme 8octets alors qu'elle est composée de 4(b::any)+1(enum type) = 5 octets?

C’est une question d’alignement : en général, les tailles des structures sont arrondies au supérieur, selon l’architecture et la taille du plus grand élément de la structure.

Ici, ton plus grand élément est un int, donc on arrondit à 4 au-dessus. Si c’était un double ET que tu es en 64*bits, on arrondirait à 8 au dessus.

La raison de ceci est simple : sur beaucoup de processeurs, lire 4 octets (32 bits) à une adresse qui n’est pas multiple de 4 est interdit. Sur d’autres (x86 notamment), c’est autorisé mais c’est beaucoup plus lent.

Du coup, le compilateur « aligne » ta structure à 8 de sorte que quand tu déclares un tableau de Variable, chaque Variable se trouve avec une adresse multiple de 4.

Enfin, il y a un coût caché que tu ne vois pas ici : boost::any contient un pointeur vers la donnée, pas la donnée directement. Ta variable fait donc en réalité en mémoire 8 + taille de donnée.

Citation:

---

Envoyé par white_tentacle

C’est une question d’alignement : en général, les tailles des structures sont arrondies au supérieur, selon l’architecture et la taille du plus grand élément de la structure.

Ici, ton plus grand élément est un int, donc on arrondit à 4 au-dessus. Si c’était un double ET que tu es en 64*bits, on arrondirait à 8 au dessus.

La raison de ceci est simple : sur beaucoup de processeurs, lire 4 octets (32 bits) à une adresse qui n’est pas multiple de 4 est interdit. Sur d’autres (x86 notamment), c’est autorisé mais c’est beaucoup plus lent.

Du coup, le compilateur « aligne » ta structure à 8 de sorte que quand tu déclares un tableau de Variable, chaque Variable se trouve avec une adresse multiple de 4.

---

Merci c'est bon à savoir :ccool:

Citation:

---

Envoyé par white_tentacle

Enfin, il y a un coût caché que tu ne vois pas ici : boost::any contient un pointeur vers la donnée, pas la donnée directement. Ta variable fait donc en réalité en mémoire 8 + taille de donnée.

---

Ouais ça j'avais deviné, ça fait vraiment beaucoup pour pas grand chose mais s'il faut faire comme ça...