Reprise du message précédent :
Ah merci Lam's ! Donc en effet je vais voir si je peux me démerder avec un autre compilo. Car c'est vrai qu'il y avait un truc qui m'intriguait, c'est que lorsque je faisais la même union, mais qu'avec une seule struct dans l'union et des variables de type int (cf. exemple 2 du premier post), ça passait sans pb. Ce n'est que lorsque je faisais une union avec au moins 2 struct que ça plantait en extern. C'est pour ça que ça me paraissait flou. Toi aussi tu utilises LabWindows ?

 
Taz dans toute sa splendeur...

et ca ?
 
extern T_Blabla maVariable = {NULL};

Yoms > tu vois bien, on se tue à t'expliquer que ton problème de déclaration mal formée n'est pas lié à extern et vice versa, mais tu t'entêtes à tout amalgamer ...

cris56 > oui là tu as tout à fait raison. C'est une erreur de ma part dans le topic, mais pas dans mon code. 2 min et je te sors le bon truc...

c'est pas très conseille ce genre de chose (est-ce que standard d'ailleurs, je commence à chercher), il faut initialiser dans la même unité de traduction que l'allocation.

Dans un fichier .h, j'ai pondu ça :

 
Bien sûr c'est un extrait et il manque les #endif
 
Dans un fichiers .c , j'écris une UNIQUE fois :
#define _DELCARE_DATA_
 
Dans tous les autres fichiers *.c qui ont besoin de voir cette variable, j'écris toujours :
#define _USE_DATA_

bon allez, je cite
 
 
"Une déclaration  externe d'un objet est une définition si elle comporte une initialisation. La déclaration d'un objet extern qui ne comporte pas d'initialiseur et qui ne contient pas le spécificateur extern est une définition potentielle. Si une unité de traduction comprend la définition d'un objet, tout définition potentielle est considérée comme déclaration redondante. Si l'unité de traduction ne comprends aucune définition de l'objet, toute définition potentielle devient une définition unique avec une valeur initiale nulle. Chaque objet doit avoir une et une seule définition." etc ...

mouef, c'est pas propre ton machin, et c'est source d'erreur.
 
dans ton foo.h tu mets

 
et tu fais un foo.c

 et là t'es blindé

Bon ben au-delà de la question de propreté qui à nous nous parait très bien comme ça (faut savori aussi qu'on pas qu'une variable, mais une chiée de variables que l'on classe dans des fichiers *.h à thèmes style le *.h de l'interface, le *. des drivers, le *.h de l'IHM, etc.) Bref, pour la propreté, là n'est pas la question.
 
Maintenant que c'est clair sur la façon dont je déclare et que j'initialise ce truc et que je suis aussi blindé de mon côté, où est le problème ? Je ne suis pas dans le cas d'une définition potentielle. Pourquoi que tout est nickel quand je ne l'utilise pas en extern ?

.....

Au cas où, j'ai bien une erreur au link et pas à la compil'

c'est pas une question de propreté : pourquoi s'ennuyer à faire des #define (et risquer une erreur) quand tout peut fonctionner sans aucune intervention de ta part ?
 
c'est quoi ton message d'erreur quand tu utilises extern ?

Je crois que ça ne sert à rien de reposer cette question, puisque Monsieur Taz ne veut pas répondre    
 
Bon, comme je l'ai dit (en m'expliquant mal sans doute), lorsque tu utilises extern, tu indiques que l'allocation s'est faite dans une autre unité de compilation (un autre .o ou .obj).  
 
Or, suivant les compilateurs, il se peut que le code généré ne sache pas à l'avance quels sont les choix d'implémentation réalisés (tu peux avoir un #pragma pack dans un seul fichier par exemple). Le compilo va donc peut-être (ça, j'en suis pas sûr), essayer de faire l'initialisation de l'extern (celle que tu nous montre avec ton = { NULL} ) en passant par le nom des variables, y compris le nom des trucs dans tes structures.  
 
Comme tu as des membres complètement anonymes dans ton union (les structures sont justes définies: tu ne déclares par d'instance de ces structures), ça chie. Ca, c'est juste une hypothèse, mais c'est celle qui me parrait la plus plausible.  
 
Dans tous les cas, ne te pose pas tant de questions : ton code est invalide : corrige-le comme te l'ont indiqué Cris56 et l'autre sociopathe et c'est tout. Si tu savais le nombre de merdes qui passent sans problèmes à la compilation avec Visual C++ 6 par exemple...

Taz > on ne fait pas toujours comme l'on veut. Il y a une méthodolgie imposée dans le labo, une façon de nommer les variables, etc. C'est comme ça, voilà tout. Maintenant, j'ai pris le pli et ça me parait clair, mais au début c'était aussi zarb'. Bref...
 
De tête car c'est au boulot : il me dit que je déclare une seconde fois "maVariable" et que cette seconde déclaration est dans un type différent que celui de la déclaration initiale. Or, c'est louche car dans le fichier *.c je ne délcare pas la variable, je l'utilise direct. J'écris par exemple :  
 
maVariable.bidulle = 5;  
 
Jamais je n'écris un truc du genre :
T_UnAutreType maVariable;
 
Et comme dit lorsque l'union ne comporte qu'une struct avec d'autres variables de type int par exemple, ça marche nickel. Dès qu'il y a 2 struct, ça devient daubique...

Lam's je comprends ce que tu veux dire, mais j'avais écarté cette solution car l'initialisation de l'extern avait déjà été faite dans le *.c où figure le
#define _DECLARE_DATA_ A partir de là, lorsqu'il linke il ne devrait pas avoir à se reposer cette question

Yoms > ouais, donc tu peux conclure toi même que ta méthode est pas sécurisée.

Sisi, tu la déclares (via l'inclusion de ton .h). Certes, tu ne la rédéfinis pas forcément (puisque c'est une extern), mais tu la déclares bel et bien dans chaque .c qui utilises ton .h

Taz > bah ça me laisse perplexe car je me dis quema méthode revient à la tienne en ce sens que lorsque je fais l'include du *.h il va bêtement me coller le contenu de ce fichier et remplacé le mot "Drivers" par extern ou que dalle selon que j'ai écrit _USE_DATA_ ou _DELCARE_DATA_. Donc si on pouvait prendre un cliché de mon *.c après cet include, il ressemblerait comme 2 gouttes d'eau à ce que tu as écris ci-dessus...
 
Mais bon, le pb il vient pas alors de la façon dont j'ai crée mon union ?!?
 
Moi je pige pas pourquoi avec une struct ça passe et 2 il pête un câble...

sort le listing du preprocesseur

Lam's> je ne la déclare que dans le *.c qui fait l'include du  *.h et qui contient la ligne de code #define _DECLARE_DATA_ avant d'écrire le #include file.h C'est aussi dans ce fichier qu'elle est initialisée. Dans ce fichier la variable est donc pleinement définie. Dans les autres fichiers, je ne la redéclare pas, j'en demande une visibilté seulment car je fais un include du même *file.h mais précédé de #define _USE_DATA_

cris56 > euh là je ne suyis pas au taf' donc...

oui, ta méthode revient à celle (canonique) que j'ai exposée. Mais la tienne te permet de t'emmêler les pinceaux. L'erreur que tu rapportes en est typiquement la preuve. On te dit pas que y a une méthode simple qui existe et qui est employée par tout le monde depuis 20ans rien que pour t'embêter. Nous la joue pas j'ai une méthode 'révolutionnaire'. Tout le monde fais un .c et un .h : sauf ceux qui n'écoute pas leur pairs.

Je n'ai jamais dit qu'elle était révolutionnaire. Toi alors ! Mais j'ai aussi des *.c et des *.h. Je pige pas ta remarque là...
 
Types.h

 
Ressource.h

 
Youpi.c

 
Piyou.c

 
Permet moi d'insister : tu la redéclares, même si tu ne la définis pas.
 
Le premier lien qui vient sous google explique pas trop mal la différence entre déclaration et définition:
 
http://www-ee.eng.hawaii.edu/Cours [...] 1.1.4.html

Euh oui oui... autant pour moi, en réécrivant proprement ce que j'ai pondu, ça apparait. Prochaine fois, j'emmènerai les fichiers chez moi, ça m'évitera de me planter et de pas avoir à rééditer 3 fois mon post pour modifier les erreurs dedans.
 
Je viens de me relire, et en fait c'était pour répondre à Taz par rapport au message d'erreur, je voulais dire que je ne la redéclare pas (sous-entendu dans un autre type comme le fait croire le compilo). Voilà, correction faite.

Ayé, je crois j'ai finis de mettre à jour le post avec tous les extraits de code. Ca donnera une bonne vue d'ensemble. En espérant que je ne me sois pas encore planté qq part.

 
Ah, mais ça le compilo ne le sait pas, puisqu'il y a des membres de ton union qui sont anonymes. Et si tu mets plusieurs membres anonymes (chacune de tes structures), c'est normal qu'il soit perdu, non ?
 
(au fait, une note pédante inutile, juste histoire que tu sois pas venu pour rien: on écrit "au temps pour moi" ).

Sur le "autant pour moi", il y a polémique, il ne sert donc à rien d'affirmer quoi que ce soit de manière pédante.
 
Sinon à part ça elle sert à quoi ton enum n°1? comment vas tu faire pour accéder à la première struct, puisque tu ne la pas nommée?
 
Ta déclaration ne sert à rien en fait. Il faut que tu nommes les structs imbriquées dans ton union:

 
et la limite tu peux utiliser des structs anonymes:

Bon c'est là ton probleme a la base:
Une union en C, c'est une union de variables (typées) et non pas une union de types. Or tu declares une union de types (des structs), et non des variables. Et le C est un langage trop primitif pour avoir directement une notion de type composé.
Que ton compilo accepte ce genre de code incorrect, c'est possible, mais ca a des limites apparement atteintes par ton code.
 
je cite le K & R:

 
A+,

 
hop puisqu'on est en à explorer toutes les possibilités foireuses du C, allons y gaiement:
 

A struct declaration defines a type. The right brace that terminates the list of members may
be followed by a list of variables, just as for any basic type. That is,
struct { ... } x, y, z;
is synta ctically analogous to
int x, y, z;
 
A structure declaration that is not followed by a list of variables reserves no storage;

du reste j'ajoute que tu es le premier sur Terre à utiliser
 
#define _RESSOURCES_
#define _USE_DATA_
 
 
y a aucun problème de collision à aucun moment, c'est nickl comme ça.
 
 
 
kikou Gilou, kikou schnaps
 
personnellement, je ne sais pas quoi faire de quelqu'un qui fait le warrior avec des .h compliqués comme pas possible pour résoudre un problème vieux comme le C, mais qui après 2 pages d'explications, se prend toujours les pieds dans le tapis pour déclarer un type ...

> hop puisqu'on est en à explorer toutes les possibilités foireuses du C, allons y gaiement:  
 
Il y a rien de foireux dans cette declaration. Tu as aussi:

   
A+,

Oui merci Gilou et schnapsmann, effectivement je n'ai pas LabWin à la maison, mais j'aurais effectivement bien testé cette modif qu'avait suggéré Taz au départ (même si on a un peu de mal à se comprendre).  
 
En fait, mon erreur et mon insitance vient du fait de ma confiance dans le compilo de LabWin comme vous le sous-entendez (tous les trois avec Lam's). C'est finalement ça la réponse à la question "Pourquoi ça marche ainsi et pas ainsi ?" : "Parce que ton compilo te le permet". Je n'ai pas remis en cause mon code, d'autant que j'avais réglé toutes les options du compilo pour qu'il ne me pardonne rien et qu'il soit le plus aggressif possible. Visiblement mon compilo a bien deviné le truc pour un usage normal, mais en extern il a jeté l'éponge...
 
Bon cela dit, le fait de devoir nommer mes struct va m'obliger à écrire :
maVariable.prout.a = 5;
au lieu de direct :
maVariable.a = 5;
Dommage c'était cool...
 
 
PS : histoire d'en rajouter une couche, je viens de me souvenir que pour cetaines raisons, certains champs des structures portaient le même nom... Je suis curieux de savoir ce que va dire le compilo si je renomme tout différemment. Arrivera-t-il à retrouver ses petits rien qu'en regardant le nom des champs ? Mais, c'est pas propre...
 
 
En tout cas, merci à tout le monde, je posterai demain pour confirmer tout ça.

[hors sujet]
En tapant "anonymous union member" sous gogol, je suis tombé sur la page du C-omega (une extension de C#) sur le site de recherche de mirosoft.
Pour ceux qui sont curieux: http://research.microsoft.com/Comega/
[/hors sujet]
A+,

 
yaisse pas mal du tout ça  

 
Si tu as des noms suffisament explicites et uniques pour tes champs finaux, ca peux se regler a coup de preprocesseur...
A+,

C'est pas propre et surtout ça ne compile pas sur les compilos munis d'une grammaire C "normale".
On nomme les membres des unions, c'est tout    
 
Content que tu aies compris, comme quoi ça sert parfois de faire des efforts de pédagogie, a+  

 
Justement, son truc est ultra typique de la programmation de DLLs sous Windows: une fois la macro dans le .h vaudra  "__dllimport", une autre fois, ça vaudra "extern", une autre fois autre chose, etc.
 
On aime ou on aime pas, de toutes façons, le sujet a déjà été abordé mille fois ici. Mais force est de constater que c'est plus une histoire de goût qu'autre choses...
 
 
PS: schnapsmann, tu l'as trouvée où la polémique sur le "autant pour moi" ?

toute façon, t'es bien eu si t'es entiers sont pas 32bits
 
gilou > rigolo, mais j'ai rien compris à la prononciation
 
 
Yoms >
 

réfléchis et tu vas voir qu'il ne peut en être autrement. C'est toi même qui nous as expliqué que les union permettent des 'vues' ... comment tu veux accéder à .a directement ? il faut spécifier que tu te place dans le contexte .prout ...