Union composée d'un boost::any

Bonjour, alors j'ai un petit problème avec un boost::any qui ne veut pas compiler tant qu'il est dans un union, je m'explique:

Code:

---

1 2 3 4 5 6 7 8

struct{ boost::any any;   bool _bool;   char _char;   }val;

---

Compile sans problème.

Code:

---

1 2 3 4 5 6 7 8

union{ boost::any any;   bool _bool;   char _char;   }val;

---

Citation:

---

error: member 'boost::any main()::<anonymous union>::any' with constructor not allowed in union
error: member 'boost::any main()::<anonymous union>::any' with destructor not allowed in union
error: member 'boost::any main()::<anonymous union>::any' with copy assignment operator not allowed in union

---

Que faut il faire pour utiliser un boost::any dans une union svp?

J'imagine que tu voulais mettre union dans ton deuxième exemple.

En C++ traditionnel, il n'est pas possible de mettre des classes avec constructeur dans une union. Juste des POD. Depuis C++11, c'est devenu possible, mais l'utilisation est quand même assez ardue (il faut utiliser du placement new et des appels explicites au destructeur à chaque fois que l'on modifie le membre actif).

La question que je me pose, c'est pourquoi mettre any dans une union, puisqu'any est déjà une sorte d'union en tant que tel ?

Remarque : On mettra en C++ plus :

Code:

---

1 2 3

struct S { };

---

que

Code:

---

1 2 3

struct { } s; // J'ai défini une variable d'un type non nommé

---

ou

Code:

---

1 2 3

typedef struct { } S;

---

Citation:

---

Envoyé par JolyLoic

J'imagine que tu voulais mettre union dans ton deuxième exemple.

En C++ traditionnel, il n'est pas possible de mettre des classes avec constructeur dans une union. Juste des POD. Depuis C++11, c'est devenu possible, mais l'utilisation est quand même assez ardue (il faut utiliser du placement new et des appels explicites au destructeur à chaque fois que l'on modifie le membre actif).

La question que je me pose, c'est pourquoi mettre any dans une union, puisqu'any est déjà une sorte d'union en tant que tel ?

---

Oui désolé, c'était bien union le deuxième (j'ai corrigé)

Sinon pourquoi mettre un any dans un union, car une union comme ci dessus fait 4 octets.

Si par exemple je veut stocker un int dans une union, si j'utilise un any, l'union fera 4(any)+4(int) octets = 8 octets

Alors que si j'utilise un int pour stocker la valeur dans l'union, cette dernière ne fera que 4octets.

C'est un moyen d'optimiser le stockage de données, bon après ça peut être une mauvaise idée si vous le dites.

Après pour ce qui est du format de la struct et de l'union, c'était juste pour montrer le bug, je vous rassure je fais ça + proprement en temps normal.

Je vais me répéter, mais tu continues de vouloir optimiser des choses qui ne méritent pas de l’être (du moins, pas tout de suite). any fait 8 en taille, tu ne peux pas faire mieux. Je ne sais pas ce que tu cherches à optimiser, là. Dans une union, il fera toujours 8 octets (l’union fait la taille de son plus grand membre).

As-tu mesuré les perfs de ton interpréteur avec un profileur ? Même si tu fais ça « pour le fun », tu apprendras plus et ça te sera plus profitable d’apprendre à utiliser le profileur, à mesurer et interpréter les résultats, plutôt qu’à faire la chasse à l’octet « perdu » et penser que ça améliorera les perfs. Tu pourrais d’ailleurs être surpris du résultat des mesures.

Citation:

---

Envoyé par white_tentacle

Je vais me répéter, mais tu continues de vouloir optimiser des choses qui ne méritent pas de l’être (du moins, pas tout de suite). any fait 8 en taille, tu ne peux pas faire mieux. Je ne sais pas ce que tu cherches à optimiser, là. Dans une union, il fera toujours 8 octets (l’union fait la taille de son plus grand membre).

As-tu mesuré les perfs de ton interpréteur avec un profileur ? Même si tu fais ça « pour le fun », tu apprendras plus et ça te sera plus profitable d’apprendre à utiliser le profileur, à mesurer et interpréter les résultats, plutôt qu’à faire la chasse à l’octet « perdu » et penser que ça améliorera les perfs. Tu pourrais d’ailleurs être surpris du résultat des mesures.

---

Là il n'est pas question de perf mais de mémoire gaspillée, et on est d'accord, la taille que prend un any est sa taille + la taille de la donnée qu'il contient. Alors qu'il est possible de stocker uniquement la donnée qu'il contient et donc d'économisé 8 octets par variables stockées (ce qui fait beaucoup au bout de 1 000 000 de variables)

EDIT: vous me conseillez quoi comme profileur?

Citation:

---

Envoyé par Nurza

Là il n'est pas question de perf mais de mémoire gaspillée, et on est d'accord, la taille que prend un any est sa taille + la taille de la donnée qu'il contient.

---

J’inclus la mémoire dans les perfs.

Citation:

---

Alors qu'il est possible de stocker uniquement la donnée qu'il contient et donc d'économisé 8 octets par variables stockées (ce qui fait beaucoup au bout de 1 000 000 de variables)

---

8 octets, c’est ton pointeur (4 si tu es en 32 bits). À noter que dans ton cas, je crois que tu dois aussi stocker le type réel de la donnée, ce que ne fait pas any. Tu peux rajouter aussi le coût du RTTI, dont any a besoin, je pense que tu l’as oublié.

Tu peux faire deux optimisations : stocker directement la donnée à la place du pointeur dans le cas des types simples, et stocker la donnée et son type de manière contigüe. Mais ça va revenir à une forme de variant (je ne comprends pas bien pourquoi tu l’as écarté, d’ailleurs, ni pourquoi tu veux gérer les constantes différemment des variables.

Enfin, sérieusement, as-tu 1000000 de variables ? Et crois-tu que c’est à ce niveau que se situera le goulot d’étranglement de ton interpréteur ?

edit : gprof est gratuit et dispo sous linux.

Citation:

---

Envoyé par white_tentacle

J’inclus la mémoire dans les perfs.



8 octets, c’est ton pointeur (4 si tu es en 32 bits). À noter que dans ton cas, je crois que tu dois aussi stocker le type réel de la donnée, ce que ne fait pas any. Tu peux rajouter aussi le coût du RTTI, dont any a besoin, je pense que tu l’as oublié.

---

Désolé je connais boost depuis pas très longtemps, donc j'ignorais si variant/any stockais la valeur ou un pointeur sur la valeur.

Pour le RTTI je l'ignorais aussi (en fait je viens d'apprendre ce que c'est)

Citation:

---

Envoyé par white_tentacle

Tu peux faire deux optimisations : stocker directement la donnée à la place du pointeur dans le cas des types simples, et stocker la donnée et son type de manière contigüe. Mais ça va revenir à une forme de variant (je ne comprends pas bien pourquoi tu l’as écarté, d’ailleurs, ni pourquoi tu veux gérer les constantes différemment des variables[/I]

---

Merci pour les conseils :ccool:

Je ne gère pas les constantes différemment c'est juste que j'ajoute un bool qui me dis si la variable est constante ou non, comme ça je vérifie à chaque accès en écriture si la variable est const ou non avant de lancer une erreur si c'est le cas.

Citation:

---

Envoyé par white_tentacle

Enfin, sérieusement, as-tu 1000000 de variables ? Et crois-tu que c’est à ce niveau que se situera le goulot d’étranglement de ton interpréteur ?

edit : gprof est gratuit et dispo sous linux.

---

C'est pas vraiment le nombre qui pose problème.
C'est si le jury qui notera le projet remarque que les variables sont stockées sur 10 octets minimum, il risque de saquer à ce niveau (en tout cas c'est ce que moi je ferais)

Merci pour gprof, je testerai ça :ccool:

Citation:

---

Envoyé par Nurza

Désolé je connais boost depuis pas très longtemps, donc j'ignorais si variant/any stockais la valeur ou un pointeur sur la valeur.

---

any stocke un pointeur vers la valeur, il ne peut pas faire autrement. Pour le variant, il est stocké en tant que valeur et pas en tant que pointeur.

Citation:

---

C'est pas vraiment le nombre qui pose problème.
C'est si le jury qui notera le projet remarque que les variables sont stockées sur 10 octets minimum, il risque de saquer à ce niveau (en tout cas c'est ce que moi je ferais)

---

Moi pas. Dans l’ordre, j’évaluerai plutôt ça comme ça (et encore, j’hésite entre le 1 et le 2) :
- fonctionnalité : le programme est fonctionnel, répond au besoin.
- clarté de la conception et de la réalisation : le programme est bien structuré, compréhensible, extensible. Par exemple : rajouter un type (au hasard, complexe) peut se faire assez facilement sans tout péter.
- l’étudiant comprend de quoi il parle, et est capable de justifier ses choix
- en dernier, la perf. Si on me sort des variables à 200 octets, oui, problème. Si on représente tout avec des strings, par exemple, oui, problème. Si on a 32 octets au lieu de 16 ou 12 pour des variables, ce n’est absolument pas grave. En bonus, je poserai la question à l’oral (si vraiment tout le reste est tout bon) de savoir si on peut diminuer cette valeur, des pistes envisagées, si des mesures de perf ont été faites, etc.

Après, je ne suis pas ton jury, je ne suis pas dans leur tête :).

Citation:

---

Envoyé par Nurza

C'est si le jury qui notera le projet remarque que les variables sont stockées sur 10 octets minimum, il risque de saquer à ce niveau (en tout cas c'est ce que moi je ferais)

---

Bonjour,
A moins qu'on vous ai donné des indications contraires, le jury va noter prioritairement:
1 - Que le code fait ce qu'on lui demande(même dans les cas particuliers)
2 - Que le code est claire et simple.(Principe KISS)
3 - Que le code est bien documenté
4 - Loin loin derrière. Que le code n'est pas trop lent, et ne prend pas trop de mémoire.

Donc j'aurais tendance a éviter les choses étrange comme une union contenant un any, qui risque de faire bondir le jury.
Après ça, choisir entre un variant, un any, ou autre... il faudrait qu'on ai plus d'explication sur la nature du problème^^. Mais dans le doute prenez celui qui vous semble le plus simple, ça me semble être un bon début.

Ok c'est noté 8-)

Je laisse tomber l'union pour un simple boost::any.

Encore merci pour vos réponses claires et rapides :ccool: