Signification d'un warning

Salut à tous.

Au cours du développement d'un projet, je suis tombé sur un warning que je n'arrive pas à expliquer :
warning: ignoring packed attribute because of unpacked non-POD field 'NOM PARTICULIER D'UN ATTRIBUT' [enabled by default]

Je veux bien vous donner du code mais ce warning ce reproduit régulièrement et a des endroits qui me semblent normaux. Google est assez avare d'explication sur ce warning =/

Pour info : je code avec avr-g++ (4.7.2) à destination d'une carte Arduino mega 2560 avec le C++11 d'activé. A noter que tout marche bien pour le moment =)

Si quelqu'un peut éclairer ma lanterne !

David

Salut,

d'après ce que je comprends et trouve sur Google, tu dois essayer de packer une structure qui contient un type complexe (donc pas un POD). Et c'est impossible.
Typiquement un vector, list, [] etc ne seront absolument pas "packables".

Certes, mais ca veut dire quoi packable ?
C'est une histoire d'alignement des champs mémoires/padding ?

Edit : Je viens de rechercher sur google et il semble effectivement que ca soit lié au padding des données.

Mais au final je ne vois pas quoi faire avec ce warning. Il m'indique juste que j'ai des attributs non-packed dans une structure packed. Qu'est ce que ca change pour moi ?

Ça change que la structure n'est pas vraiment packed. Et donc, si tu tentes de l'écrire directement dans un fichier binaire, tu peux avoir (en plus des problèmes d'endianness) des octets de bourrage insérés à des endroits où tu ne t'y attends pas.

La bonne réponse pour écrire ça dans un fichier binaire est de sérialiser manuellement ta structure au lieu de faire un gros write() de la structure entière.

Salut,

Citation:

---

Envoyé par Davidbrcz

Certes, mais ca veut dire quoi packable ?
C'est une histoire d'alignement des champs mémoires/padding ?

---

En tout cas, cela a trait à ce qui est autorisé pour les types POD.

C++11 apporte des précisions quant à ce qui est nécessaire pour obtenir un objet de type POD qui sont très clairement de nature à permettre d'obtenir un avertissement si l'une ou l'autre des structures n'est pas de type POD ;)

Pour info, C++11 définit maintenant deux "concepts" qui doivent tous deux être respectés pour les types POD:

• Le concept de "type trivial"
• Le concept de "standard layout"

Un type est considéré comme trivial si

• il ne propose pas de constructeur par défaut non trivial
• il ne propose pas de constructeur par copie non trivial
• il ne propose pas de constructeur par déplacement non trivial
• il ne propose pas d'opérateur d'affectation non trivial
• il ne propose pas d'opérateur d'affectation par déplacement non trivial
• il ne propose pas de destructeur non trivial.
• ses éventuelles classes de base ne proposent que des fonctions triviales
• ses différents membres sont eux même triviaux

Pour que toutes ces fonctions puissent être considérées comme triviales, il faut

• Soit qu'elles ne soient purement et simplement pas déclarées (de manière à laisser le compilateur les implémenter de manière automatique)
• Soit qu'elles soient déclarée comme étant "default"

Ainsi, une structure proche de

Code:

---

1 2 3 4 5 6 7 8 9

struct MyStruct { // aucune des fonctions "de base" sus-citée n'est déclarée int i; double d; long l; char str[10]; int tab *; };

---

sera considérée comme triviale, de même que la structure

Code:

---

1 2 3 4 5

struct Derived : public MyStruct // MyStruct est triviale comme je l'ai dit plus haut { Derivied() = default; float ftab[10]; };

---

Par contre, une structure proche de

Code:

---

1 2 3 4 5 6

struct NonTrivial { int i; std::string str; // std::string est non triviale, du fait de ses nombreux // constructeurs non triviaux et de son destructeur };

---

ou proche de

Code:

---

1 2 3 4 5

struct NonTrivialCauseVirtualDtor { virtual ~NonTrivialCauseVirtualDtor(); // non trivial pour cause de virtualité int i; };

---

ne sera pas considérée comme triviale.

Le "concept" de "standard layout" va, quant à lui, essentiellement s'intéresser à la manière dont les données sont représentées en mémoire dans la structure.

Un type est considéré comme "standard layout" si:

1. il n'a aucun membre non statique qui ne soit pas "standard layout "
2. il n'a ni fonction virtuelle ni héritage virtuel
3. Tous ses membres non statiques sont soumis au même contrôle d'accès
4. il ne dérive pas d'une classe n'étant pas "standard layout"
5. either has no base class with non-static data members or has no non-static data members in the most derived class and only one base with them (pas certain de la traduction à donner de cette phrase :aie:)
6. n'a pas de classe de base du même type que son premier membre non statique

Bref, comme tu peux le constater, il y a maintenant pas mal de restrictions apportées à ce que l'on peut considérer comme étant un type POD ;)

Il y a tout lieu de croire que tu te trouves régulièrement dans une situation dans laquelle le compilateur estime que tu veux travailler avec des types POD alors que les conditions ne seraient pas toutes remplies pour qu'il puisse effectivement considérer les types envisagés comme tels ;)

Citation:

---

Il y a tout lieu de croire que tu te trouves régulièrement dans une situation dans laquelle le compilateur estime que tu veux travailler avec des types POD alors que les conditions ne seraient pas toutes remplies pour qu'il puisse effectivement considérer les types envisagés comme tels

---

La présence de l'attribut "packed" est un bon indice du désir de travailler en POD.

Citation:

---

Envoyé par Médinoc

La présence de l'attribut "packed" est un bon indice du désir de travailler en POD.

---

En effet :D

Oki, merci beaucoup ! Sujet résolu