Discussion :

[uknow]

Bonjour,

Je vous explique le contexte avant de poser la question.

J'ai développé une DLL en C; cette DLL attend un pointeur génériques void* de l'application cliente (l'application qui utilise cette DLL). Je voudrais savoir si le pointeur générique void* sera correctement réceptionné par la DLL; autrement dit est-ce qu'il sera compatible avec un pointeur void* issu d'une application cliente codée en C++ ? (à quelles condition ce passage fonctionne-t-il ?)
Est-ce que la déclaration du pointeur en extern "c" est suffisante pour ne pas avoir de surprises ?

(bien évidemment la machine qui a construit la DLL n'est pas la même que celle sur laquelle l'application cliente est construite; pour enlever le cas d'architecture 32/64 on admettra qu'on est sous deux architectures 32 bits).

Merci d'avance pour toutes vos remarques sur le sujet.

[Obsidian]

Empiriquement, un pointeur étant censé contenir une adresse mémoire, on peut légitimement penser qu'il sera codé de la même façon sur une même machine mais, effectivement, il faudrait corréler les passages des normes des deux langages pour pouvoir l'affirmer « scientifiquement ».

Par contre, j'ai effectivement tendance à penser qu'un « extern "C" » suffirait à faire rentrer les choses dans l'ordre si elles avaient besoin de l'être puisque c'est précisément sa fonction (communiquer avec le C).

Donc, oui, ça devrait suffire. C'est, bien sûr, ce qu'il y a derrière le pointeur qu'il faudra examiner de plus près, puisque complètement rendu abstrait par void. S'il y a des structures de données connues à l'avance, il faudra également inclure leurs déclarations dans ton « extern "C" ».

[uknow]

Merci de ta réponse,

Oui effectivement le pointeur void* cachera derrière lui une adresse d'une structure de données quelconque. la DLL se fiche de savoir ce que c'est, car elle n'effectue pas de traitement dessus, elle se contente de le mettre en argument d'une callback (sous la forme d'un void*).

Pour le extern "c", est-ce une règle valable pour le pointeur void* (*)(void*) également ?

Et pour un pointeur void*(*)(void*) dans la DLL censé recevoir l'adresse d'une fonction C++ (pas une méthode de classe) pour l'appeler; est-ce que l'appel sera correct ? (à quelles conditions ?).

[Melem]

C'est la fonction que tu désires appeler en C++ que tu dois déclarer extern "C" dans le code C++. Il n'y a aucun problème pour les types.

[uknow]

Merci pour vos confirmations. Je mets le sujet en résolu mais si quelqu'un d'autre a une remarque sur le sujet c'est toujours la bienvenue.

[Sve@r]

Merci de ta réponse,

Oui effectivement le pointeur void* cachera derrière lui une adresse d'une structure de données quelconque. la DLL se fiche de savoir ce que c'est, car elle n'effectue pas de traitement dessus, elle se contente de le mettre en argument d'une callback (sous la forme d'un void*).

Hum. Le void* sert à faire transiter des choses diverses et variées. Si toi tu ne fais transiter qu'une seule et même chose (une structure bien définie), pourquoi ne pas mettre directement un pointeur sur cette structure ?
Le fait que la fonction qui le reçoit le passe simplement à sa voisine sans aucun autre traitement ne lui interdit pas de connaitre et bien définir le type de ce pointeur. Et si la voisine callback reçoit ce pointeur dans un void*, tant mieux pour elle mais c'est pas pour ça que tu dois, toi, le mettre en void* dans tes propres fonctions...

[uknow]

En fait il s'agit d'une DLL, donc elle n'est pas censée connaitre la nature de la structure qui elle est définie dans l'application cliente.

De même la fonction est définie dans l'application cliente; la DLL dispose d'un pointeur void* p1 et d'un pointeur void*(*p2)(void*); le p2 sera déréférencé pour appeler la fonction en lui passant en paramètre p1. Sans savoir ce que c'est. Un peu dans le même principe de pthread.

Mon but étant que la DLL soit le plus générique/portable possible.