Discussion :

[poukill]

Bonjour à tous,

Aujourd'hui, je sèche sur un problème relativement simple avec boost::bind. Ca fait 1 heure que je sèche et ça m'énerve. La fatigue me direz-vous... Sans doute !

Vois un exemple de code minimal qui reproduit mon problème : je cherche à appeler un callback membre avec une signature spécifique. La classe Agent provient d'une bibliothèque tierce qui appelle une fonction ayant un prototype précis (Agent::Func ici) pour passer les infos.
Le seul truc que je peux toucher, c'est ma classe Test !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
#include <iostream>
#include <boost/bind.hpp>
 
struct foo {};
struct bar {};
 
void free_callback(foo*, bar*)
{}
 
class Agent
{
public:
	typedef void (*Func)( foo*, bar* );
 
	virtual bool Initialize ( const char* name, Agent::Func p_func = NULL ) {}
};
 
class Test
{
public:
	Test()
	{
		m_agent = new Agent;
		m_agent->Initialize("mon_agent", free_callback); // OK
		m_agent->Initialize("mon_agent", boost::bind(&Test::CallBack, this, _1, _2) ); // KO
	}
	~Test()
	{
		delete m_agent;
	}
 
private:
	void CallBack(foo*, bar*);
 
	Agent* m_agent;
};
 
int main()
{
    return 0;
}

Compilo :

error C2664: 'Agent::Initialize'*: impossible de convertir le paramètre 2 de 'boost::_bi::bind_t<R,F,L>' en 'Agent::Func'

[Mat007]

Salut,

Le type construit par l'appel à boost::bind n'est pas de type Agent::Func mais de type implementation-defined.
Tu peux remplacer Agent::Func par un boost::function< void( foo*, bar* ) > pour que ça fonctionne.

MAT.

[poukill]

Salut Mat !
Arg, j'ai oublié de préciser. Je ne maitrise PAS la class Agent, elle vient d'une autre bibliothèque !

EDIT: je crois avoir trouvé un début de solution.

Code :

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

1
2
3
4
5
6
7
8
9
 
Test()
{
	m_agent = new Agent;
	m_agent->Initialize("mon_agent", free_callback); // OK
	boost::function<void(foo*, bar*)> f = boost::bind(&Test::CallBack, this, _1, _2);
	Agent::Func* f2 = f.target<Agent::Func>();
	m_agent->Initialize("mon_agent", *f2 ); // OK
}

Maintenant je sais pas trop ce que ça vaut...

RE EDIT : ça vaut rien du tout....

[Mat007]

C'est quoi la vraie signature de la callback ? Y'a pas un void* prévu pour passer des données utilisateur ?

MAT.

[Mat007]

je crois avoir trouvé un début de solution.

Je ne pense pas que ça fonctionne, cf. http://lists.boost.org/Archives/boos.../12/145709.php par exemple.

MAT.

[poukill]

Je ne pense pas que ça fonctionne, cf. http://lists.boost.org/Archives/boos.../12/145709.php par exemple.

MAT.

Effectivement, ça ne marche pas du tout...
http://stackoverflow.com/questions/2.../512233#512233 est un autre exemple....

Du coup, je crois bien que je suis coincé...

@MAT: la vraie signature de la callback est celle que j'ai montré. Sauf qu'évidement c'est pas foo et bar, mais ça ne change rien... J'attends un message d'une bibliothèque tierce vers une fonction avec une signature spécifique !

[Mat007]

Et t'as pas moyen de convaincre les auteurs de Agent qu'il faut au moins un void* sinon c'est pas très utilisable (sauf si Test est un singleton bien sûr mais bon...) ?

MAT.

[jblecanard]

Je suis d'accord, c'est quand même étrange que tu ne puisses pas avoir de données utilisateur à récupérer dans la callback. Ca fait perdre beaucoup de l'intérêt du système.

[poukill]

Et t'as pas moyen de convaincre les auteurs de Agent qu'il faut au moins un void* sinon c'est pas très utilisable (sauf si Test est un singleton bien sûr mais bon...) ?
MAT.

Si y'a moyen, je peux avoir des contacts avec. C'est pas super simple, mais c'est très faisable.
Test n'est pas un singleton, en effet, mais il pourrait le devenir si je trouve pas de solutions et que ça m'arrange... Parce que là, si j'arrive pas à mettre une fonction membre en callback, le code va vite devenir très moche (variable globale et tout). Ce que je voudrais vraiment éviter.

Je suis d'accord, c'est quand même étrange que tu ne puisses pas avoir de données utilisateur à récupérer dans la callback. Ca fait perdre beaucoup de l'intérêt du système.

Well, je suis pas sûr de comprendre ce que vous avancez tous les 2!
En fait, je vois pas en quoi le void* m'aiderait. A partir du moment où une signature est imposée, je suis marron. Le paramètre implicite "this" me casse en deux. Je pense pas que le void* peut améliorer la chose. Si?
Pour développer un peu, la bibliothèque tierce avec l'Agent en question est une façade pour un système de communication middleware DDS. Là, ma classe "Test" veut juste écouter un certain type de message, et éventuellement en émettre quelques uns. Mais comme les messages sont très "formalisés" (structures complètement définies à l'avance, avant la compilation), ben y'a pas vraiment de données ou type utilisateur. Je sais pas si je suis très clair...
En tout cas, merci bien pour le coup de main !

[Mat007]

En fait, je vois pas en quoi le void* m'aiderait.

En général en C lorsqu'on positionne une callback on passe un paramètre utilisateur que l'on va ensuite recevoir lors de l'appel de la callback, pour justement gérer un contexte d'appel.
Et comme c'est du C, c'est souvent un void*.

Du coup là en plus du pointeur de fonction tu passerais l'instance de Test en faisant un transtypage vers un void*, que tu récupérerais dans l'appel de la callback et que tu pourrais transtyper dans l'autre sens en Test*.

Mais bon là en fait c'est du C++ donc ils devraient accepter une callback sous la forme d'une interface (genre classe virtuelle pure, et tout ça...).

MAT.

[jblecanard]

Mais bon là en fait c'est du C++ donc ils devraient accepter une callback sous la forme d'une interface (genre classe virtuelle pure, et tout ça...).

Ou un boost.function dans nos rêves les plus fous

[poukill]

Ok, je comprends.
Au passage, je me rends compte que j'ai probablement mal nommé ma fonction. En réalité c'est pas vraiment une callback puisque il n'y a pas vraiment d'appel préalable. En fait, on s'enregistre à la manière du pattern observer sur un domaine, et on attend des messages qui peuvent arriver à n'importe quel moment.
Dans tous les cas, c'est vrai que la manière C++ de faire les choses c'est :

• une classe abstraite avec un membre virtuel pur
• boost.Signals
• boost.Function

.
Bon bah là j'ai aucun des 3, j'ai tout gagné !

Je me pose une question quand même : est-ce que les 3 solutions que je viens de mentionner fonctionnent en exportation via une DLL de manière portable ? i.e pas de problèmes de mangling, couple new/delete, etc... (cf discussion ICI )
Si c'est faisable, alors il ne me reste plus qu'à contacter l'équipe de dev pour négocier une meilleure interface.

[Mat007]

est-ce que les 3 solutions que je viens de mentionner fonctionnent en exportation via une DLL de manière portable ?

Les deux dernières non et la première sans doute mais peut-être pas (et réciproquement).
Si vraiment il faut que ça soit portable-portable alors il faut du C (et un void*).

MAT.

[poukill]

Les deux dernières non et la première sans doute mais peut-être pas (et réciproquement).
Si vraiment il faut que ça soit portable-portable alors il faut du C (et un void*).

MAT.

Grrrrr, j'avais peur de cette réponse.

Mais quand même, une simple interface comme celle là :

Code :

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

1
2
3
4
5
6
 
class IObserver
{
public:
    virtual void Notify(foo*, bar*) = 0;
};

Avec éventuellement foo* et bar* en pointeur intelligent pour que la libération se fasse dans la DLL (ou alors via un foo->Delete() ).
Ca ne devrait pas poser problème, c'est simplissime.
D'après cet article, ça devrait marcher !

Good news, non ?

[Emmanuel Deloget]

Pas possible, même une interface simple comme ça.

Si le code est compilé avec deux compilateurs différents, rien ne dit que

* les deux compilateurs vont utiliser une vtable
* la structure de la vtable sera la même
* la vtable s'utilise de la même manière

[poukill]

OK.
Et livrer la DLL compilé avec n compilateurs, sur windows et linux, c'est une utopie c'est ça ?
Genre gcc 4.4.3 et gcc 4.4.4 c'est pas garanti non plus ?

[Emmanuel Deloget]

OK.
Et livrer la DLL compilé avec n compilateurs, sur windows et linux, c'est une utopie c'est ça ?
Genre gcc 4.4.3 et gcc 4.4.4 c'est pas garanti non plus ?

Dans le principe, non ; en pratique, c'est fort probable que ça fonctionne quand même - il y a peu de chance que d'une version mineure à l'autre, les changements dans l'ABI C++ soient si importants qu'ils provoque une incompatibilité totale ; d'ailleurs, il faut quand même pouvoir linker le code fait avec g++4.3 et celui compilé avec g++4.4 - et si ça marche pour les librairies statiques, alors il y a des chances que ça marche pour les .so.

Le même genre de remarque est valable pour Visual C++ : un programme compilé avec la version 2003+ a de bonne chance de pouvoir importer des plugins de la version 2010, à condition que les allocation/libération de mémoire n'entrent pas en concurrence (la mémoire allouée par un module (au sens Windows, c'est à dire disposant d'un HMODULE au runtime) est libérée par ce même module).

Mais il faut savoir que le standard ne garanti rien, et que c'est un détails d'implémentation choisi par le vendeur - il peut où non le modifier par la suite.

[poukill]

Dans le principe, non ; en pratique, c'est fort probable que ça fonctionne quand même - il y a peu de chance que d'une version mineure à l'autre, les changements dans l'ABI C++ soient si importants qu'ils provoque une incompatibilité totale ; d'ailleurs, il faut quand même pouvoir linker le code fait avec g++4.3 et celui compilé avec g++4.4 - et si ça marche pour les librairies statiques, alors il y a des chances que ça marche pour les .so.

Le même genre de remarque est valable pour Visual C++ : un programme compilé avec la version 2003+ a de bonne chance de pouvoir importer des plugins de la version 2010, à condition que les allocation/libération de mémoire n'entrent pas en concurrence (la mémoire allouée par un module (au sens Windows, c'est à dire disposant d'un HMODULE au runtime) est libérée par ce même module).

Mais il faut savoir que le standard ne garanti rien, et que c'est un détails d'implémentation choisi par le vendeur - il peut où non le modifier par la suite.

Si on est obligé de faire du C pur pour utiliser des .DLL / .so, moi j'abandonne!
Pourtant dans l'article que j'avais cité, le gars explique qu'en C++ on peut exporter sans crainte une interface C++ sans variables membres. A condition que les paramètres soient des POD, ou bien eux même des interfaces abstraites.
Ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
// The abstract interface for Xyz object.
// No extra specifiers required.
struct IXyz
{
    virtual int Foo(int n) = 0;
    virtual void Release() = 0;
};
 
// Factory function that creates instances of the Xyz object.
extern "C" XYZAPI IXyz* APIENTRY GetXyz();

fait ce qu'on lui demande correctement. En encapsulant soi-même le IXyz::Release comme fonction de nettoyage dans un shared_ptr, on reste C++ avec même un peu de RAII en prime !

Moi j'ai l'impression que cette voie est une porte de sortie pour moi pour gérer cette interface contraignante Agent (cf mon premier post). Après, il faut voir ce que voulait exactement dire l'auteur par interface abstraite dans le prototype des fonctions. C'est là que ça peut coincer AMHA.

Je raconte n'importe quoi ou ça un sens ce que je dis ?

[Emmanuel Deloget]

Généralement, ce type d'article est écrit par des gens qui vont tester sur Visual, puis sur g++, mais jamais en croisé.

Comme je l'ai dit plus haut, rien de garanti que les deux compilateurs vont traiter de la même manière les classes abstraites. Par exemple, VC++ mets une vtable, dont la taille est sizeof(R C::*)()) * nombre de fonction virtuelle, à l'adresse de l'objet, typiquement gardée dans le registre ecx. Lorsqu'on appelle une fonction virtuelle, le compilateur prends son index, et compose l'adresse d'appel grâce à ecx. Il effectue ensuite un jmp à l'adresse trouvée en release ; en debug il fait des tas d'autres choses mais le protocole d'appel est compatible. Du coup, en release, l'appel à une méthode virtualle coute le coût de l'appel à une fonction normale + un mov + jmp (c'est relativement bien optimisé).

Si g++ fait exactement la même chose, alors les DLL produites pourront être compatibles. Mais qu se passe-t-il si g++ garde le pointeur de l'objet dans un autre registre ? Que se passe-t-il si la pile n'est pas gérée de la même manière (par exemple, un compilateur, en mode optimisation, passe un des arguments via un registre car la fonction consiste essentiellement à modifier la valeur passée et à la retourner. Par exemple, une fonction qui fait square(x) ou x est un entier pourrait très bien être optimisée ainsi :

Code :

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

1
2
3
4
5
6
7
 
// protocole d'entrée supprimé
// le compilateur sait qu'il a directement mis la valeur de x dans eax
// eax est aussi le registre dans lequel on stocke typiquement la valeur de
// retour
mul eax,eax,eax
ret

Que faire si, ignorant cette optimisation, l'autre compilateur génère un appel à sq en passant x via la pile ?

Il y a trop de problèmes à suivre, trop de cas tordus à vérifier ; j'envie celui qui a trouvé le temps de vérifier tout ça - sur VS2003, VS2005, VS2008, VS2010, g++ 4.0 à g++ 4.6 (comme ce sont des détails d'implémentation, des versions différentes peuvent quand même gérer les choses légèrement différemment).

[Jean-Marc.Bourguet]

Genre gcc 4.4.3 et gcc 4.4.4 c'est pas garanti non plus ?

gcc suit un ABI normalisé pour le C++, il y a de l'interopérabilité avec les autres compilateurs qui le suivent (au moins celui d'Intel pour Linux).

Voir http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html

Et pour la lib standard:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html