Discussion :

[mitkl]

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

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"

[Nurza]

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"

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

[gbdivers]

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

[white_tentacle]

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

[Nurza]

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.

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.

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

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

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.

[white_tentacle]

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

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

[Nurza]

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.

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>

[white_tentacle]

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.

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

[Nurza]

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

[white_tentacle]

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 !

[Nurza]

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.

[gbdivers]

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

[Nurza]

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?

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

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

[Nurza]

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 :

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

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?

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

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.

[Nurza]

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

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