Bonjour, depuis plusieurs moi je réalise des DLLs qui sont compatible sous VC++ et BCB. Je les crée sous VC++ et je transforme le .lib avec COFF2OMF. Tout marchais bien jusqu'au jour ou j'ai décidé de ne plus exporter des fonctions (en extern "C" ), mais l'interface d'un objet.
 
Pour cela je crée le .h que je livre avec ma library  
 
class Titi_interface
{
public :
   virtual void fonction1() = 0;
   virtual void fonction2() = 0;
}
 
extern "C" __declspec(dllexport) void* QueryObject();
 
La fonction QueryObject est faite comme ça :
void* QueryObject() { return(new Titi) };
 
et dans l'implémentation de la library je réalise la classe Titi :
 
class Titi : public Titi_interface
{
   void fonction1();
   void fonction2();
}
 
Du coup l'utilisateur utilise mon programme comme ça :
Titi_interface *T;
T = (Titi_interface *) QueryObject();
T->fonction1();
 
Il n'a pas acces à la classe Titi c'est un peu comme avec COM/COM+ je crois.
 
Le truc c'est qu'avec VC++ ma DLL marche nickel, mais avec BCB c'est le gros bazar, les arguments que je passe aux fonctions membres ne sont pas ce que je reçois dans ma DLL, j'ai plein d'erreur d'acces...
 
Quelqu'un aurait il une idée ?
 
Je me demande si s'est pas une histoire de stcall ou un truc du genre. J'avais réalisé de la meme maniere une Bibliotheque sour BCB et ça marchait tres bien sous BCB...

Ca remonte à loin tout ça pour moi.  
 
Mais en gros, il faut que Visual C++ et Borland utilisent la même convention d'appel (stdcall par exemple). C'est d'ailleurs ce que tu fais implicitement je crois en préfixant ton QueryObject d'un declspec(dllexport).  
 
Or, par défaut, l'un des deux utilisera thiscall, c'est à dire qu'il met le pointeur this dans un registre plutôt que dans la pile.
 
Le problème, c'est que je n'ai aucune idée du comment-faire pour changer tout ça. Cherche le web, ou demande éventuellement à antp...

Je crois que c'est plutot un probleme de name mangling qui est différent entre les 2 compilos.
http://www.cppbuilderdevjournal.co [...] _a_DLL.htm

Oui, c'est pour ça (entre autres) qu'il passe par une interface anonyme (comme le montre très bien ton lien dans le Listing A).  
 
Mais ça n'explique pas pourquoi il se choppe plein de paramètres dans le vent.

Il me semble que VC++ encode (lors du name mangling) une convention d'appel d'une manière que BCB décode comme une autre (une histoire de _ devant si j'ai bonne mémoire)...
Rappelez moi le but des dll ?

Yup, c'est la différence entre stdcall et fastcall que tu nous donne là en terme de mangling (et encore, il y a juste le _ du début. On est loins des incompatibilités de C++ sous unix).  
 
Sinon, pour les DLL, c'est triste à dire et ce n'est pas un glorieux standard, mais COM est quand même un super modèle pour faire coexister des composants hétérogènes. Surtout que BCB est capable de les importer comme sa poche...
 

Bon en demandant au compilo de décoré avec __cdecl comme ça :
 
class Titi_interface  
{  
public :  
   virtual void __cdecl fonction1() = 0;  
   virtual void __cdecl fonction2() = 0;  
}
 
Ca marche sous BCB nickel, mais plus sous VC++    
 
Vous pensez qu'il faut que je mette en place des directives de compilation pour pouvoir compiler en __cdecl pour BCB et en __stdcall, ou y'a un autre moyen plus simple ?
 
Sinon est ce que je peux rajouter une configuration a mon projet du genre Release BCB, et joué sur une variable d'état que je lit dans mon prog avec des directives de compilation du style :
 
#ifdef __RELEASE__BCB
  #define DLLEXPORT __cdecl
#else
  #define DLLEXPORT __stdcall
#endif
 
Mais dans ce cas la je sais pas comment on fait pour créer __RELEASE__BCB automatiquement.. dans les arguments du compilo ?

Ca me parrait très bancal...  

Compile 2 fois ta dll et livre les 2 versions...

bon allez, je file la solution
sous C++ Builder, tu restes en __declspec, et tu créé un fichier .def que tu ajoutes à ton projet, dans le genre :
 

et basta, la dll sera lisible par n'importe quel exe créé avec VC++ (fonctionne pour moi pour une dll créé avec BCB et relue par Winamp, pour un plugin)