Discussion :

[jobigoud]

Bonjour,
J'espère que la question n'a pas été traitée plusieurs fois et que je n'aurais pas trouvé dans mes recherches...

Nous avons un executable 32bits qui charge une dll 32bits, cette dernière exposant un certain nombre de fonctions. (Jusque là rien que de très classique )

La dll doit pouvoir être compilée avec n'importe quel compilateur.

Se posera-t-il un problème pour la taille des types transitant entre les deux ?

bool, int, enums, long risquent-ils d'être plus ou moins grands et ainsi faire péter l'exe ?
Quid des structures ?

Nous avons déjà éliminé l'hypothèse d'utiliser des classes, car elles seraient selon toute probabilité stockées différemment en mémoire. (Un header regroupant les types définis sera compilé de chaque côté)

Comment le cas est-il géré pour les dll qu'on trouve en liberté dans la nature ? existe-il un risque que les données passées ne fassent pas la même taille entre l'appelant et l'appelé ?

(Sans parler de compilateurs 64bits ou 16bits ici, merci.)

Merci d'avance !

[Luc Hermitte]

1- Mauvais forum

2- Investissez dans Imperfect C++ de Matthew Wilson, chez Addisson-Wesley, un chapitre (voire plus) est consacré à ces problèmes.

Sinon, sur un même OS, je serai surpris que les tailles des types changent vu que normalement on est censé avoir la compatibilité au niveau C. Au pire, indiquez très exactement ce que vous voulez utiliser.
Par contre, pour les aggrégats, attention aux alignements.

[jobigoud]

Merci,

Quel serait-le bon forum ? Sachant que nous serons effectivement sur le même OS (windows 32 bits, XP/2000) pour la dll et l'exe, et que ce sera du C++ des deux côtés.

A propos de la compatibilité au niveau du C, c'est justement là dessus que nous nous posions des questions, merci pour ces premières indications.

[Luc Hermitte]

Sur les techniques particulières pour simuler des classes, ici peut-être.
Sinon ... "dev windows" ? Mais bon, le risque est je pense nul vu que ces types sont censés être compatibles au niveau de l'interface C (aux détails d'alignement)

[JolyLoic]

Il n'est pas si nul, par exemple un int du C n'est pas la même chose qu'un integer en VB. Il y a une correspondance entre différents types de différents langages, mais elle n'est pas forcément immédiate à trouver.

Si on veut avoir des classes dans des DLL sous windows, soit on se limite en terme de langage/compilateurs compatibles, soit on fait du COM (beark, même si c'est un peu moins beark que ça l'a été).

[jobigoud]

un int du C n'est pas la même chose qu'un integer en VB.

Ma grande interrogation est : un int du C compilé avec VC++98 (par ex.) est il la même chose qu'un int du C compilé avec GCC ou Borland C++.
Puis-je partir du principe qu'absolument 100% des compilos vont utiliser 4 octets pour leurs int ? (Je crois me souvenir que le standard n'impose pas de taille précise, mais juste un ordonnancement entre les short,int, et longs )

Sachant que je développe le programme principal qui va appeller une sorte de Plugin sous la forme d'une dll développée par un tiers, sous un compilateur éventuellement différent du mien.

Comment puis-je connaitre les petites différences entre les compilos, au niveau de l'alignement des octets dans le stockage des structures par exemple ?
Existe-il une doc regroupant ces infos, ou il faut se palucher les manuels de tous les compilateurs possibles ?

Est-ce que c'est un risque tangible, ou plutôt insignifiant, s'il existe un consensus entre les divers compilateurs à ce propos.

merci

[Luc Hermitte]

Les bibliothèques en C étant censées être compatibles avec tous les compilos, je dirais que pas de problème pour les int.
J'ai donné le nom de la source qui contient le plus d'infos sur le sujet, parmi celle que je connais. Pour le reste, il faut consulter la doc de chaque compilo.

[nicroman]

Et pourtant....

http://www.developpez.net/forums/showthread.php?t=33235

Non, les types 'standard' ne sont pas compatibles d'un compilateur à un autre. Il existe de fortes présomptions pourque deux compilateurs ayant pour cible le même processeur et le même OS produisent des types compatibles, mais franchement, je n'y mettrai pas ma main à couper.

Pour communiquer entre deux éléments "inconnus", rien ne vaut des types stricts (int8, ...). Chaque compilo a les siens, mais au moins, on est sur du final.

[galak63]

après danston code il faudra que tu utilises tes "propres" types, définis selon l'OS, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifdef WIN32
#define INTEGER int
#else
#define INTEGER long
#endif

un truc comme çà en gros

[Luc Hermitte]

Que les types C de base ne soient pas compatibles entre eux sur une même plateforme, même avec des compilos différents, me parait bizarre.
Et assez incompatible avecle fait qu'il me semblait bien que le C était le langage pour lequel il y avait une ABI commune sur toutes les plateformes -- aux détails de l'alignement et des ordres de passages de paramètres.

[jobigoud]

après danston code il faudra que tu utilises tes "propres" types, définis selon l'OS, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifdef WIN32
#define INTEGER int
#else
#define INTEGER long
#endif

un truc comme çà en gros

Oui, c'est un peu ce que nous avons fait pour être sûr à 100%... Mais c'est justement parceque je trouvais un peu laid dans le code d'avoir ces types redéfinis partout, que je me demandais si c'était bien utile...

De plus comme la taille des enums est définie sur la taille de int, cela nous a obligé a détyper tous nos enums avec notre nouveau type int garanti 32 bits...
C'est très génant lorsqu'on remplit une de ces variable avec n'importe quel int 32 bits, alors qu'elle n'est censée avoir qu'une plage de valeurs réduite bien définie...

Je vais essayer de trouver la doc des compilos pour en avoir le coeur net...

[Jean-Marc.Bourguet]

Que les types C de base ne soient pas compatibles entre eux sur une même plateforme, même avec des compilos différents, me parait bizarre.
Et assez incompatible avecle fait qu'il me semblait bien que le C était le langage pour lequel il y avait une ABI commune sur toutes les plateformes -- aux détails de l'alignement et des ordres de passages de paramètres.

Plus precisement, les bons vendeurs d'OS publient une ABI pour leur systeme, qui comprend l'alignement et la maniere de passer les parametres, et d'autres contraintes (du genre qu'on peut ou pas dependre des donnees situees sous le pointeur de pile). Ou parfois plusieurs (SGI a change d'ABI par exemple); quand on change, on essaie d'empecher l'edition de liens (utiliser des decorations de noms differentes est la technique utilisee par les compilateurs C++; des compilateurs C ont fait de meme avec un _ initial; on peut aussi utiliser un champs dans l'entete des fichiers objets).

Dans le passe, MS a change d'ABI sans prevenir et sans prendre les precautions necessaires pour empecher l'edition de liens. Je doute qu'ils l'aient fait depuis Windows, car Windows depend fortement de bibliotheques dynamiques. Je ne sais pas s'ils en ont publie une ou que les autres ont simplement deduit du comportement des compilo MS l'ABI utilisee.

Parfois genant, parfois utile, certains compilateurs offrent la possibilite de controler certains aspect de l'ABI (controle de l'alignement, passage des parametres par registre) avec des flags ou des pragma. La coherence est alors a charge des programmeurs.

[Jean-Marc.Bourguet]

après danston code il faudra que tu utilises tes "propres" types, définis selon l'OS, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifdef WIN32
#define INTEGER int
#else
#define INTEGER long
#endif

un truc comme çà en gros

typedef plutot que define.