Discussion :

[HanLee]

Bonjour,

Pour réaliser mes bindings entre C++ et OCaml, j'utilise l'interface C fournie avec la distribution.

Comme il y a un Garbage Collector dans OCaml, si j'utilise une classe non POD, il faut fournir une fonction de finalisation.

Le problème, c'est que j'utilise une fonction de finalisation template.
Vis-à-vis de l'interface C, je me demandais si ça posait pas de problème de donner l'adresse d'une fonction template (instanciée bien sûr) à une fonction C ?

Merci d'avance.

[JolyLoic]

Je ne vois pas trop de problèmes a priori, même si je serais bien surpris que quoi que ce soit garantisse ce genre de fonctionnement.

Le seul cas tordu auquel je pense serait un compilateur qui n'aurait pas la même convention de passage de paramètres en C et en C++, ce qui ferait qu'à un code C, tu ne pourrais passer un pointeur de fonction C++ que si cette dernière était déclarée extern "C".

[HanLee]

Je ne vois pas trop de problèmes a priori, même si je serais bien surpris que quoi que ce soit garantisse ce genre de fonctionnement.

Le seul cas tordu auquel je pense serait un compilateur qui n'aurait pas la même convention de passage de paramètres en C et en C++, ce qui ferait qu'à un code C, tu ne pourrais passer un pointeur de fonction C++ que si cette dernière était déclarée extern "C".

C'est justement ce dernier cas que je crains.

Comment faire alors ? Boost.Python a surement du rencontrer ce problème. Avec la bibliothèque de préprocessing de Boost pour générer des extern "C" à la volée peut-être ?

[Kujara]

Je ne vois pas trop de problèmes a priori, même si je serais bien surpris que quoi que ce soit garantisse ce genre de fonctionnement.

Le seul cas tordu auquel je pense serait un compilateur qui n'aurait pas la même convention de passage de paramètres en C et en C++, ce qui ferait qu'à un code C, tu ne pourrais passer un pointeur de fonction C++ que si cette dernière était déclarée extern "C".

Les conventions de parametres en c++ ne sont plus forcement les même qu'en c, normalement pas de difference d'apres ce que j'en ai lu, mais sous visual c++, 3 conventions possibles en c++ : __cdecl( standard c), __stdcall( standard win32 c++), __fastcall( non standard).

Donc ça va effectivement dependre du compilateur, donc il faut tester et voir ce que ça donne.

[Médinoc]

Pour les fonctions libres ou statiques, sous Windows il n'y a aucune différence entre C et C++ : Les deux n'utilisent que les trois conventions d'appel __cdecl, __stdcall et __fastcall.
Par contre, une fonction membre non-statique d'une classe est en thiscall si on ne spécifie pas une autre convention (c'est le cas notamment pour les interfaces COM, dont les fonctions membres sont en __stdcall pour être utilisables en C).


Sous d'autres OS, aucune garantie que je connaisse (mais je ne connais pas les normes par coeur). C'est ce qui fait qu'un typedef de pointeur de fonction peut être ou non dans un bloc extern "C" {}...

[HanLee]

OK. En fait, je pense que c'est pas trop un problème : sous VC++ on peut forcer la convention d'appel des fonctions libres en __cdecl.

Je sais pas pour g++, mais je suppose que si les signatures étaient les mêmes, j'aurais eu une erreur.

On va dire que c'est résolu.

[Médinoc]

À l'intérieur même d'un programme C ou C++, toutes les fonctions libres sont généralement en __cdecl (et les fonctions membres non-statiques en thiscall).
D'ailleurs, le compilateur choisit __cdecl par défaut si on ne lui dit pas de faire autrement (il compile en /Gd par défaut).

Par contre, les fonctions exportées par une DLL sont généralement explicitement déclarées en __stdcall, pour pouvoir être appelées depuis un autre langage que C ou C++ (notamment VB).