Discussion :

[Neckara]

Bonjour,

J'ai un programme principal qui charge dynamiquement une bibliothèque à l'exécution.

Cette bibliothèque a une interface précise :

Code :

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

1
2
3
4
5
6
class IBar {
         virtual void foo(void) = 0;
         virtual void faa(void) = 0;
}
 
IBar & foo(void);

Quand je charge ma bibliothèque, je recherche donc le symbole foo et je reçoit un void *.
Sauf que ma bibliothèque peut avoir plusieurs implémentations différentes et je n'ai aucune garantie de la validité des symboles dans une implémentation.
De plus, une bibliothèque peut se retrouver invalide si elle a été compilée avec un compilateur différent que celui qui a compilé l'exécutable.

J'ai donc pensé à compiler une bibliothèque "vide" :

Code :

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

1
2
3
4
5
6
class IBar {
         virtual void foo(void) = 0;
         virtual void faa(void) = 0;
}
 
IBar & foo(void){}

Celle-ci pourrait être fournie avec l'exécutable.
Dès lors, j'aurais les symboles (ex. 3fooZA_IBar_foo_faa) exacts générés par le compilateur et je pourrais les comparer avec ceux de la bibliothèque que je chargerais.

Par contre, je n'ai pas beaucoup de connaissances sur les ABI des compilateurs, est-ce que vous auriez une idée pour effectuer cette comparaison de la manière la plus efficace possible ?

[Neckara]

Pour g++, j'ai réussi à trouvé deux/trois choses (si on ne déclare pas les fonctions comme "extern C") :

Les fonctions sont précédées de _Z.
On donne ensuite la taille du nom de la fonction puis le nom de la fonction.

Ensuite, pour chaque argument on donne la taille du nom du type de l'argument puis son nom. Le tout précédé de "R" pour une référence et de "P" pour un pointeur.

Exemple : _Z3fooR4IBar.


En revanche, impossible de vérifier à vu d’œil le type de l'argument retourné ni de vérifier les classes.
J'essaye de continuer de creuser.

[Neckara]

Pour les classes, après réflexion, c'est un peu normal de ne rien voir pour une classe virtuelle pure.

Pour une classe "normale" sans méthodes inlines :

_ZN3BarC2Ev\00_ZTV3Bar\00_ZN3BarC1Ev\00_ZN3Bar3fooEii\00_ZN3BarC2ERKS_\00_ZN3BarC1ERKS_\00_Z4totoR3Bar\00_ZTI3Bar\00_ZTVN10__cxxabiv117__class_type_infoE\00_ZTS3Bar

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Bar
{
    public :
    Bar(void);
    virtual void foo(int, int);
};
 
Bar::Bar(void)
{
 
}
 
void Bar::foo(int,int){}

Il faut donc que je continue de creuser à ce niveau là.
Par contre, pour les arguments de retours, je ne sais pas encore comme bien les vérifier...


EDIT :
Je peux faire des classes "virtuelles" mais il faut que celui qui implémente la bibliothèque implémente un constructeur, c'est pas génial, mais au moins, on a des symboles :

Code :

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

1
2
3
4
5
ELF

\00\00\00\00\00\00\00\00\00\00>\00
\00\00\00`\00\00\00\00\00\00@\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00@\008\00\00@\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00D    \00\00\00\00\00\00D    \00\00\00\00\00\00\00\00 \00\00\00\00\00
\00\00\00\00\00\00H    \00\00\00\00\00\00H     \00\00\00\00\00H     \00\00\00\00\00\98\00\00\00\00\00\00\A0\00\00\00\00\00\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\90    \00\00\00\00\00\00\90     \00\00\00\00\00\90     \00\00\00\00\00\F0
\00\00\00\00\00\00\F0
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\90
\00\00\00\00\00\00\90
\00\00\00\00\00\00\90
\00\00\00\00\00\00$\00\00\00\00\00\00\00$\00\00\00\00\00\00\00\00\00\00\00\00\00\00P\E5td\00\00\00\9C\00\00\00\00\00\00\9C\00\00\00\00\00\00\9C\00\00\00\00\00\00$\00\00\00\00\00\00\00$\00\00\00\00\00\00\00\00\00\00\00\00\00\00Q\E5td\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00GNU\00A}\C9N\9CmAE\9EQ\CD\FC\F9\EFm\95\00\00\00\00\00\00\00    \00\00\00
\00\00\00\00\00\00\88\E4!$D        \00\00\00\00\00\00\00\00\00\B2<\D7Z\BA\E3\92|CE\D5\EC    R
\90R=\D8qX\B9\8D\F1"w\8C&\EA\D3\EFe{\8C&\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00a\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\008\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00R\00\00\00"\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\AC\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\96\00\00\00\00\00|\00\00\00\00\00\00\00\00\00\00\00\00\002
\00\00\00\00\E8 \00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\00\BF\00\00\00!\00 \00\95\00\00\00\00\00\00\00\00\00\00\00\00\00\A3\00\00\00!\00\00\80     \00\00\00\00\00\00\00\00\00\00\00\00\81\00\00\00!\00\00`     \00\00\00\00\00\00\00\00\00\00\00\00&
\00\00\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\8A\00\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\8C\00\00\00\00\00\00\00\00\00\00\00\00\00\00u\00\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00__gmon_start__\00_init\00_fini\00_ITM_deregisterTMCloneTable\00_ITM_registerTMCloneTable\00__cxa_finalize\00_Jv_RegisterClasses\00_ZN3BarC2Ev\00_ZTV3Bar\00_ZN3BarC1Ev\00_Z4totoR3Bar\00_ZTI3Bar\00__cxa_pure_virtual\00_ZTS3Bar\00_ZTVN10__cxxabiv117__class_type_infoE\00libstdc++.so.6\00libm.so.6\00libgcc_s.so.1\00libc.so.6\00_edata\00__bss_start\00_end\00CXXABI_1.3\00GLIBC_2.2.5\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00
\00
\00
\00
\00
\00
\00
\00
\00
\00
\00\00\00
\00
\00\EE\00\00\00\00\00\00 \00\00\00ӯk\00\00\007
\00\00\00\00\00\00
\00
\00
\00\00\00\00\00\00\00\00\00ui    \00\00\00B
\00\00\00\00\00\00H     \00\00\00\00\00\00\00\00\00\00\00\000\00\00\00\00\00\00P     \00\00\00\00\00\00\00\00\00\00\00\00\F0\00\00\00\00\00\00\D8 \00\00\00\00\00\00\00\00\00\00\00\00\D8 \00\00\00\00\00h     \00\00\00\00\00
\00\00\00 \00\00\00\00\00\00\00\00\00\00\00p     \00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80     \00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\88     \00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\88 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\90 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\98 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\A0 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\A8 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C8 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D0 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00H\83\ECH\8Bm \00H\85\C0t\E8#\00\00\00H\83\C4\C3\00\00\00\00\00\00\00\00\00\00\00\00\00\00\FF5\82 \00\FF%\84 \00@\00\FF%\82 \00h\00\00\00\00\E9\E0\FF\FF\FF\FF%z \00h
\00\00\00\E9\D0\FF\FF\FFH\8D=y \00H\8Dy \00UH)\F8H\89\E5H\83\F8vH\8B \00H\85\C0t    ]\FF\E0fD\00\00]\C3fffff.\84\00\00\00\00\00H\8D=9 \00H\8D52 \00UH)\FEH\89\E5H\C1\FEH\89\F0H\C1\E8?H
\C6H\D1\FEtH\8B\D1 \00H\85\C0t]\FF\E0f\84\00\00\00\00\00]\C3fffff.\84\00\00\00\00\00\80=\E9 \00\00u'H\83=\A7 \00\00UH\89\E5tH\8B=\CA \00\E8=\FF\FF\FF\E8H\FF\FF\FF]\C6\C0 \00
\F3\C3fffff.\84\00\00\00\00\00H\8D=!
 \00H\83?\00u\E9^\FF\FF\FFfD\00\00H\8B9 \00H\85\C0t\E9UH\89\E5\FF\D0]\E9@\FF\FF\FFUH\89\E5H\89}\F8H\8BE\F8H\8B% \00H\8DRH\89]\C3UH\89\E5H\89}\F8H\8BE\F8]\C3\00\00H\83\ECH\83\C4\C33Bar\00\00\00
; \00\00\00\00\00\00\94\FE\FF\FF<\00\00\00\C4\FF\FF\FFd\00\00\00\E0\FF\FF\FF\84\00\00\00\00\00\00\00\00\00\00
zR\00
x
\90
\00\00$\00\00\00\00\00\00P\FE\FF\FF0\00\00\00\00FJw\80\00?;*3$"\00\00\00\00\00\00\00D\00\00\00X\FF\FF\FF\00\00\00\00A\86C W\00\00\00\00\00\00d\00\00\00T\FF\FF\FF\00\00\00\00A\86C I\00\00\00\00\00\00\00\00\00\00\000\00\00\00\00\00\00\F0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\EE\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\FD\00\00\00\00\00\00\00
\00\00\00\00\00\00\00
\00\00\00\00\00\00
\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 \00\00\00\00\00\00\00\8C\00\00\00\00\00\00\00\00\00\00\00\00\00H     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00P     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\F5\FE\FFo\00\00\00\00\B8
\00\00\00\00\00\00\00\00\00\00\00\00\00\E8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00N
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\B0 \00\00\00\00\00\00\00\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D8\00\00\00\00\00\00\00\00\00\00\00\00\00\A0\00\00\00\00\00\00\00\00\00\00\00\00\008
\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\FE\FF\FFo\00\00\00\00`\00\00\00\00\00\00\FF\FF\FFo\00\00\00\00\00\00\00\00\00\00\00\F0\FF\FFo\00\00\00\006\00\00\00\00\00\00\F9\FF\FFo\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\90     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00F\00\00\00\00\00\00V\00\00\00\00\00\00\D8 \00\00\00\00\00GCC: (Debian 4.9.1-15) 4.9.1\00\00.symtab\00.strtab\00.shstrtab\00.note.gnu.build-id\00.gnu.hash\00.dynsym\00.dynstr\00.gnu.version\00.gnu.version_r\00.rela.dyn\00.rela.plt\00.init\00.text\00.fini\00.rodata\00.eh_frame_hdr\00.eh_frame\00.init_array\00.fini_array\00.jcr\00.data.rel.ro\00.dynamic\00.got\00.got.plt\00.data\00.bss\00.comment\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\90
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\B8
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\006\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\A0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\8C\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 \00\95\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\9C\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00H     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00P     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00X     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00`     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\90     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\80 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\B0 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D8 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\F1\FF\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00X     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00.\00\00\00\00\00\A0\00\00\00\00\00\00\00\00\00\00\00\00\00\00A\00\00\00\00\00\F0\00\00\00\00\00\00\00\00\00\00\00\00\00\00W\00\00\00
\00\00\E0 \00\00\00\00\00
\00\00\00\00\00\00\00f\00\00\00
\00\00P     \00\00\00\00\00\00\00\00\00\00\00\00\00\8D\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\99\00\00\00
\00\00H     \00\00\00\00\00\00\00\00\00\00\00\00\00\B8\00\00\00\00\F1\FF\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\F1\FF\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C1\00\00\00
\00\00@    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\CF\00\00\00
\00\00X     \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\F1\FF\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\DB\00\00\00
\00\00\B0 \00\00\00\00\00\00\00\00\00\00\00\00\00\F1\00\00\00
\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\00\FD\00\00\00
\00\00\D8 \00\00\00\00\00\00\00\00\00\00\00\00\00

\00\00
\00\00\90     \00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00|\00\00\00\00\00\00\00\00\00\00\00\00\00 
\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00,
\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00;
\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00O
\00\00\00\00\8C\00\00\00\00\00\00\00\00\00\00\00\00\00\00U
\00\00!\00 \00\95\00\00\00\00\00\00\00\00\00\00\00\00\00^
\00\00!\00\00\80     \00\00\00\00\00\00\00\00\00\00\00\00g
\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\83
\00\00!\00\00`     \00\00\00\00\00\00\00\00\00\00\00\00\8C
\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\A6
\00\00"\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C2
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\F4
\00\00\00\00`\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\00+\00\00\00\00\E8 \00\00\00\00\00\00\00\00\00\00\00\00\000\00\00\00\00\E0 \00\00\00\00\00\00\00\00\00\00\00\00\007\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00crtstuff.c\00__JCR_LIST__\00deregister_tm_clones\00register_tm_clones\00__do_global_dtors_aux\00completed.6659\00__do_global_dtors_aux_fini_array_entry\00frame_dummy\00__frame_dummy_init_array_entry\00lib2.cpp\00__FRAME_END__\00__JCR_END__\00_GLOBAL_OFFSET_TABLE_\00__TMC_END__\00__dso_handle\00_DYNAMIC\00_Z4totoR3Bar\00_ZN3BarC1Ev\00__gmon_start__\00_Jv_RegisterClasses\00_fini\00_ZTS3Bar\00_ZTI3Bar\00_ITM_deregisterTMCloneTable\00_ZTV3Bar\00_ITM_registerTMCloneTable\00__cxa_finalize@@GLIBC_2.2.5\00_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3\00_ZN3BarC2Ev\00__cxa_pure_virtual@@CXXABI_1.3\00__bss_start\00_end\00_edata\00_init\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\90
\00\00\00\00\00\00\90
\00\00\00\00\00\00$\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00.\00\00\00\F6\FF\FFo\00\00\00\00\00\00\00\B8
\00\00\00\00\00\00\B8
\00\00\00\00\00\00P\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\008\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E0
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00@\00\00\00\00\00\00\00\00\00\00\00\00\00\E8\00\00\00\00\00\00\E8\00\00\00\00\00\00N
\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00H\00\00\00\FF\FF\FFo\00\00\00\00\00\00\006\00\00\00\00\00\006\00\00\00\00\00\00(\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00U\00\00\00\FE\FF\FFo\00\00\00\00\00\00\00`\00\00\00\00\00\00`\00\00\00\00\00\00@\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00d\00\00\00\00\00\00\00\00\00\00\00\00\00\A0\00\00\00\00\00\00\A0\00\00\00\00\00\008
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00n\00\00\00\00\00\00B\00\00\00\00\00\00\00\D8\00\00\00\00\00\00\D8\00\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00x\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00s\00\00\00
\00\00\00\00\00\00\00\00\00\000\00\00\00\00\00\000\00\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00~\00\00\00
\00\00\00\00\00\00\00\00\00\00`\00\00\00\00\00\00`\00\00\00\00\00\00*
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\84\00\00\00
\00\00\00\00\00\00\00\00\00\00\8C\00\00\00\00\00\00\8C\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\8A\00\00\00
\00\00\00\00\00\00\00\00\00\00\95\00\00\00\00\00\00\95\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\92\00\00\00
\00\00\00\00\00\00\00\00\00\00\9C\00\00\00\00\00\00\9C\00\00\00\00\00\00$\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\A0\00\00\00
\00\00\00\00\00\00\00\00\00\00\C0\00\00\00\00\00\00\C0\00\00\00\00\00\00\84\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\AA\00\00\00\00\00\00\00\00\00\00\00\00\00H     \00\00\00\00\00H    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\B6\00\00\00\00\00\00\00\00\00\00\00\00\00P     \00\00\00\00\00P    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C2\00\00\00
\00\00\00\00\00\00\00\00\00\00X     \00\00\00\00\00X    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\C7\00\00\00
\00\00\00\00\00\00\00\00\00\00`     \00\00\00\00\00`    \00\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D4\00\00\00\00\00\00\00\00\00\00\00\00\00\90     \00\00\00\00\00\90    \00\00\00\00\00\00\F0
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\DD\00\00\00
\00\00\00\00\00\00\00\00\00\00\80 \00\00\00\00\00\80\00\00\00\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E2\00\00\00
\00\00\00\00\00\00\00\00\00\00\B0 \00\00\00\00\00\B0\00\00\00\00\00\00(\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\EB\00\00\00
\00\00\00\00\00\00\00\00\00\00\D8 \00\00\00\00\00\D8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\F1\00\00\00\00\00\00\00\00\00\00\00\00\00\E0 \00\00\00\00\00\E0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\F6\00\00\00
\00\00\000\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\E0\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\FD\00\00\00\00\00\00\FF\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 \00\00\00\00\00\00\D0\00\00\00\00\00\00\00\00\00,\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00    \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\D0\00\00\00\00\00\00=\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00

Il faut quand même que je vérifie qu'on peut bien se passer des "extern C" pour utiliser dlsym() et getSymbole().
Restera plus qu'à trouver comment tenter de vérifier les types de retours et exactement quels symboles rechercher/ignorer pour comparer deux dll efficacement.

[bacelar]

Heu, pourquoi ne pas utiliser les Framework de composants/plugIns qui sont fait pour ça ?

[Neckara]

dlsym est très bête et va rechercher le symbole tel quel.

Si on utilise extern "C", il ne va écrire que toto au lieu de _Z4totoP4IBar.

Donc soit on perd l'information en utilisant extern "C" soit on la conserve mais il faudra écrire _Z4totoP4IBar à la place, ce qui dans mon cas est pas très gênant vu que je peux faire des recherches dans la "dll vide".

Heu, pourquoi ne pas utiliser les Framework de composants/plugIns qui sont fait pour ça ?

Pour ne pas intégrer de dépendances, je ne veux pas que mon exécutable ai la moindre dépendances.

[bacelar]

>Pour ne pas intégrer de dépendances, je ne veux pas que mon exécutable ai la moindre dépendances.
Mais bien sûr, t'as même réimplémenté la lib C et le Kernel et tous les drivers, GG.

Et faire un truc "indépendant" mais qui se base sur un mangling de g++, non documenté, c'est carrément Kafkaïen.

Tu cherches à réinventer une roue carrée. Et si tu avais pris la peine de voir comment les autres ont implémentés ces Frameworks, que tu décris sans même connaitre, tu aurais vu des choses comme des fonctions implémentant des Design Pattern Factory et des trucs comme de IUID et des CUID venant de Corba et autres IDL, COM, XCOM etc.

Si ton but est d'avoir une architecture à composant ou à base de plugIn, ouvres les yeux, t'as en 2014, t'es pas un pionnier du Far West.

[Neckara]

>Pour ne pas intégrer de dépendances, je ne veux pas que mon exécutable ai la moindre dépendances.
Mais bien sûr, t'as même réimplémenté la lib C et le Kernel et tous les drivers, GG.

Et faire un truc "indépendant" mais qui se base sur un mangling de g++, non documenté, c'est carrément Kafkaïen.

Qui a dit que je me basais sur le mangling de g++ ?
Pour le moment je cherche à comprendre le fonctionnement.

Tu cherches à réinventer une roue carrée. Et si tu avais pris la peine de voir comment les autres ont implémentés ces Frameworks, que tu décris sans même connaitre, tu aurais vu des choses comme des fonctions implémentant des Design Pattern Factory et des trucs comme de IUID et des CUID venant de Corba et autres IDL, COM, XCOM etc.

Ah ? Et avec un DP Factory, IUID ou CUID, je peux vérifier la compatibilité d'ABI C++ entre les différents compilateurs ?

En quoi un DP Factory pourrait m'aider ?
D'ailleurs j'ai un peu de mal à voir en quoi un CUID va m'aider à protéger ma dll d'une mauvaise implémentation d'un utilisateur.

Et puis bon, j'ai aussi le droit de faire ce que je veux non?
Si j'ai envie de coder un pong, j'ai le droit non? Oui, cela a déjà été codé un nombre incalculable de fois et alors ?

[bacelar]

cela a déjà été codé un nombre incalculable de fois et alors ? .

Comme les roues carrées, mais on a déjà trouvé la roue plus ou moins ronde, autant s'en inspirer.

Qui a dit que je me basais sur le mangling de g++ ?
Pour le moment je cherche à comprendre le fonctionnement.

Ok, mais faut bien comprendre que le mangling C++ est tout sauf standard, ce que vous essayez de comprendre sera à jeter dés que vous aurez plusieurs chaines de compilation.

Ah ? Et avec un DP Factory, IUID ou CUID, je peux vérifier la compatibilité d'ABI C++ entre les différents compilateurs ?

Pas besoin de la vérifier, c'est garantie par la conformité au mangling C, qui lui est standardisé, comme ses conventions d'appels d'ailleurs.
La fonction factory sera exportée en C, pas en C++. Pas besoin d'objets et de classes pour un DP Factory.
L'usage de IUID et autre COCLASSID permet de passer des arguments à cette factory sans être lié a aucun langage car leur représentation est langage agnostique (même machine agnostique).

En clair, vous vous faites des noeuds au cerveau sur des sujets qui ont déjà été mainte fois résolue de manières élégantes.
Et vous ne prenez même pas la peine de regarder comment ils ont fait.

Je peux être aussi narcissique que vous et vous vomir ce que d'autres, bien plus doués, ont trouvés, mais je suis pas comme ça (oui, c'est surtout que j'ai la flemme de m'en rappeler).

Donc regardez n'importe quel Framework de PlugIns ou de composants. S'ils ont duré, c'est qu'il y a de très très bonnes idées dedans.

COM, avec toutes les features qu'il proposait (appartement, catégorisation, chargement out-of-process, late binding, auto-publication, déchargement automatique de composant, transaction répartie, etc...) n'utilisait que 4 fonctions C, et pas une de plus.

Et vous savez quoi ? L'une d'elle, c'était une fonction factory.

[Neckara]

Comme les roues carrées, mais on a déjà trouvé la roue plus ou moins ronde, autant s'en inspirer.

Et il m'est donc impossible de réfléchir un peu par moi-même ?
Je n'ai donc pas le droit de m'amuser et de "bidouiller" ?

Ok, mais faut bien comprendre que le mangling C++ est tout sauf standard, ce que vous essayez de comprendre sera à jeter dés que vous aurez plusieurs chaines de compilation.

Je n'ai pas besoin du mangling, juste de savoir si déjà je peux, en récupérant des symboles d'un .so "vide" vérifier la validité d'un autre .so qui lui implémente la bibliothèque.

Pas besoin de la vérifier, c'est garantie par la conformité au mangling C, qui lui est standardisé, comme ses conventions d'appels d'ailleurs.
La fonction factory sera exportée en C, pas en C++. Pas besoin d'objets et de classes pour un DP Factory.

Sauf que l'ABI C++ n'est absolument pas standardisé, donc on sera bien malin en récupérant notre instance de classe C++ via notre factory...

L'usage de IUID et autre COCLASSID permet de passer des arguments à cette factory sans être lié a aucun langage car leur représentation est langage agnostique (même machine agnostique).

Donc je lui passe un identifiant et elle me sort un void * ?
Et comment tu vérifies qu'il va bien me sortir un Foo et pas un Bar ? Comment tu vérifies que ton Foo respecte l'interface ?

Je peux être aussi narcissique que vous

Tu as écris un Hello World en commençant à apprendre à programmer ? Quel narcissique tu es ! Il y a des personnes bien plus compétentes que toi qui ont codé des Hello World bien meilleurs !

[jo_link_noir]

Je te conseille d’abandonner l'idée de regarder le mangling : les types de retours sont ignorés car inutile à la surcharge de fonction (seul vc++ les ajoutent).

Si tu veux vérifier la validité d'un .so, base toi sur les headers fournit avec. Mais bon, il y a sûrement des outils pour ça.

[Neckara]

Je te conseille d’abandonner l'idée de regarder le mangling : les types de retours sont ignorés car inutile à la surcharge de fonction (seul vc++ les ajoutent).

Oui, c'est plutôt dommage .

Si tu veux vérifier la validité d'un .so, base toi sur les headers fournit avec. Mais bon, il y a sûrement des outils pour ça.

Sauf que je n'ai pas le header du .so quand je compile l'exécutable.
J'ai un header qui décris l'interface que devrait avoir le .so mais je n'ai pas vraiment de moyen de vérifier que le .so a tout implémenté correctement et s'il n'a pas été tenté de modifier l'header.

Je peux par exemple dire : vous devez implémenter toutes les classes virtuelles pures INom avec une classe héritante publiquement de celles-ci et nommée Nom.
Vous devez aussi avoir une fonction de prototype ?? & load(void);.

En comparant les symboles entre une "implémentation vide" et une réelle implémentation, il devrait alors être possible de vérifier la présence de tous les symboles.
Toujours est-il que pour la compatibilité d'ABI (sjlj, dw2, etc.), je pense qu'il y a un symbole à regarder, mais je ne sais pas encore lequel et je ne sais pas s'il est possible d'obtenir ces informations avec des variables préprocesseur (?).


Je vais tenter de réfléchir un peu cette nuit.


EDIT : Je vais regarder un peu le format ELF ( http://fr.wikipedia.org/wiki/Executa...inkable_Format ).
Pour Windows, il me semble qu'ils utilisent un autre format non?

[bacelar]

Vous y tenez à votre roue carrée.

Tous les arguments que vous donnez montre que le problème n'est pas trivial et qu'il faut l'expérience accumulée depuis des décennies pour les régler.
Mais voilà, malgré le fait que vous soyez étudiante, vous vous foutez de toute première étape du article de recherche, l'étude bibliographique.

Sauf que l'ABI C++ n'est absolument pas standardisé, donc on sera bien malin en récupérant notre instance de classe C++ via notre factory...

Justement, en n'utilisant qu'une fonction factory, vous pouvez encapsuler les objets "natifs" dans des coquilles (intercepteurs) en charge de faire respecter une ABI que vous avez spécifié.
COM le fait en spécifiant une ABI qui n'autorise que des interfaces avec des méthodes et des types pour les paramètres qui respectent cette ABI ou les types VARIANTS du système.
En claire, votre "void*", c'est une vtable avec 4 fonctions virtuelles qui, entre autre, gère la vie de l'objet et son typage.
L'utilisation d'IDL, venant de CORBA, permet de générer directement les squelettes des classes et des intercepteurs qui respectent l'ABI.

Le fait de n'exporter qu'une fonction factory, ayant une signature déterminée, renvoyant des interfaces V_Table avec les premières fonctions gérant l'identification du composant, réduit pour le moins drastiquement la probabilité d'avoir un faut positif.

Et une classe C++ ne va pas s'enregistrer dans le mécanisme de la Factory par accident.

Sauf que je n'ai pas le header du .so quand je compile l'exécutable.

Comme c'est bizarre, COM utilise un système dit de TypeLibrary en ressource de ces dll de composant. Directement généré par le compilateur IDL. Et cette infrastructure permet de générer directement les fichiers d'en-tête ou équivalents en fonction du langage cible.

Pour Windows, il me semble qu'ils utilisent un autre format non?

C'est le format PE
http://en.wikipedia.org/wiki/Portable_Executable

Si vous voulez faire une roue, regardez au moins un dessin de roue pour connaitre la forme.

Je cite COM car je le connais bien, mais il existe des dizaines de solutions alternatives, comme les plugIns de Qt, de Firefox, de VS, etc..

[Neckara]

Tous les arguments que vous donnez montre que le problème n'est pas trivial et qu'il faut l'expérience accumulée depuis des décennies pour les régler.
Mais voilà, malgré le fait que vous soyez étudiante, vous vous foutez de toute première étape du article de recherche, l'étude bibliographique.

Je ne fais pas de thèses pour le moment .
Je fais cela pour moi et je m'amuse, je test, je bidouille.

Quel est l'intérêt de faire une étude bibliographique de différentes implémentations de morpion, de calculer la complexité des ses algorithmes, etc. quand on veut juste faire un petit morpion sans prétentions pour mettre en pratique ses connaissances ou se dérouiller les mains ?

L'informatique, ce n'est pas qu'un métier, c'est aussi une passion, où est le problème si je m'amuse ?

Justement, en n'utilisant qu'une fonction factory, vous pouvez encapsuler les objets "natifs" dans des coquilles (intercepteurs) en charge de faire respecter une ABI que vous avez spécifié.
COM le fait en spécifiant une ABI qui n'autorise que des interfaces avec des méthodes et des types pour les paramètres qui respectent cette ABI ou les types VARIANTS du système.
En claire, votre "void*", c'est une vtable avec 4 fonctions virtuelles qui, entre autre, gère la vie de l'objet et son typage.
L'utilisation d'IDL, venant de CORBA, permet de générer directement les squelettes des classes et des intercepteurs qui respectent l'ABI.

C'est quand même dommage de se priver des exceptions alors qu'on développe en C++.
D'ailleurs, je me demande même si on a le droit d'utiliser des méthodes virtuelles dans notre interface (les vtables pouvant avoir une implémentation différente selon le compilateur (?) ).

Et une classe C++ ne va pas s'enregistrer dans le mécanisme de la Factory par accident.

J'ai l'impression que ce dont tu nous parles, n'est pas une simple factory.
Tu as l'air d'avoir un hash de l'entête ou les données de l'en-tête dans ta Factory pour vérifier que l'exécutable et le plugin ont bien la même définition.
Donc soit un hash soit une sorte de structure permettant de faire de l'introspection sur la classe, c'est bien cela (?).

Comme c'est bizarre, COM utilise un système dit de TypeLibrary en ressource de ces dll de composant. Directement généré par le compilateur IDL. Et cette infrastructure permet de générer directement les fichiers d'en-tête ou équivalents en fonction du langage cible.

Donc ajouter quelque chose généré par le compilateur IDL à la fin du fichier .so ou .dll.
Par contre intégrer un compilateur IDL dans ma chaîne de compilation, c'est loin d'être une petite dépendance.


Par contre, la nuit portant conseil, j'ai eu une petite idée pour quelque chose de plus idiot proof et de plus simple, je vais continuer à y réfléchir avant de vous la présenter.

[bacelar]

Quel est l'intérêt de faire une étude bibliographique de différentes implémentations de morpion

Bin, mettre à plat ce qu'est le morpion, je crois qu'il n’y a pas moins de 4 ou 5 règles axiomatiques, qu'il faut bien isoler des corolaires.
Les évolutions du jeu dans le temps.
Les axes d'amélioration déjà explorées.
Les domaines d'expérimentation et d'application du système et de son étude.
Je tiens à rappeler que la théorie des jeux est un concept cardinal en économie moderne et que le morpion est l'un des jeux (avec les échecs et le go) qui à permit l'émergence de celle-ci. Et puis c'est la base du message du super film "Wargames".

L'informatique, ce n'est pas qu'un métier, c'est aussi une passion, où est le problème si je m'amuse ?

T'as pas encore atterri, c'est une industrie. Et en comme développeur en France, t'es pas près d'être en haut de la pyramide de Maslow.

C'est quand même dommage de se priver des exceptions alors qu'on développe en C++.

COM/OLE permet d'encapsuler des types et des messages d'erreur en implémentant des interfaces dédiés.
Il suffit aux stubs (intercepteurs coté composant) de convertir ces exceptions en les sérialisant dans les résultats d'appels.
Les proxys (intercepteurs coté client du composant) de reconstruire le ou les exceptions (COM/OLE supporte le concept de multi-erreurs) dans l'environnement du client en désérialisant les résultats d'appels.

les vtables pouvant avoir une implémentation différente selon le compilateur

Cela fait partie de l'ABI que vous devez maintenir, les intercepteurs peuvent s'en charger. Comme par hasard, l'ABI sur la vtable est conforme à ce que fait VC++.

c'est loin d'être une petite dépendance

Dépendance à quoi ? Le format IDL est normalisé par CORBA. Et faire des outils qui le respect, c'est pas de "rocket science".
L'avantage est considérable et c'est nettement plus simple que l'ASN1 de nos amis d'IBM.

j'ai eu une petite idée pour quelque chose de plus idiot proof et de plus simple

C'est souvent les meilleurs.
Mais faut aussi admettre que ça marche pas à tout les coups.

[Neckara]

Bin, mettre à plat ce qu'est le morpion, je crois qu'il n’y a pas moins de 4 ou 5 règles axiomatiques, qu'il faut bien isoler des corolaires.
Les évolutions du jeu dans le temps.
Les axes d'amélioration déjà explorées.
Les domaines d'expérimentation et d'application du système et de son étude.
Je tiens à rappeler que la théorie des jeux est un concept cardinal en économie moderne et que le morpion est l'un des jeux (avec les échecs et le go) qui à permit l'émergence de celle-ci. Et puis c'est la base du message du super film "Wargames".

Si tu veux le faire toi-même de ton côté, je ne t'en empêche pas.
Mais là c'est moi qui code, c'est moi qui m'amuse sur mon temps libre pour mon plaisir, j'utilise la méthodologie que je souhaite.
Si cela ne te plaît pas, tu n'as qu'à le faire toi-même avec ta propre méthodologie, mais laisse tranquille les autres.

Là, c'est moi qui code, pas toi. Quand tu coderas je te laisserais utiliser la méthode que tu veux (cycles en V, agile, etc.) alors laisse moi utiliser la mienne.
Pour un simple morpion qui me permettrait juste de me familiariser avec un langage/bibliothèque, etc. je m'en moque de l'évolution du jeu dans le temps, je me moque des améliorations, je me moque de tout ça pour un simple projet qui va me prendre 30 minutes et que je laisserais tomber par la suite.

Si développer en C++ ne t'amuses pas, n'empêche pas ceux dont cela amuse s'amuser avec !

T'as pas encore atterri, c'est une industrie. Et en comme développeur en France, t'es pas près d'être en haut de la pyramide de Maslow.

Qui a dit que je serais développeur ou que je le resterais ?

COM/OLE permet d'encapsuler des types et des messages d'erreur en implémentant des interfaces dédiés.
Il suffit aux stubs (intercepteurs coté composant) de convertir ces exceptions en les sérialisant dans les résultats d'appels.
Les proxys (intercepteurs coté client du composant) de reconstruire le ou les exceptions (COM/OLE supporte le concept de multi-erreurs) dans l'environnement du client en désérialisant les résultats d'appels.

Ceci est loin d'être simple et ajoute des contraintes supplémentaires qui sont loin d'être triviales.

Dépendance à quoi ? Le format IDL est normalisé par CORBA. Et faire des outils qui le respect, c'est pas de "rocket science".
L'avantage est considérable et c'est nettement plus simple que l'ASN1 de nos amis d'IBM.

Oui mais quitte à faire, je préfère éviter d'ajouter des étapes à la compilation et conserver une chaîne de compilation la plus simple possible.

C'est souvent les meilleurs.

J'ai pu m'en rendre compte à de maintes occasions .
Là j'ai essayé de penser à la méthode la plus bourrin pour vérifier un .so/.dll, et au final, la solution la plus bourrin n'est pas de vérifier le contenu mais le comportement.
C'est à dire que je ne vérifie pas les types mais que le .so/.dll se comporte comme il le devrait, ce qui devrait être suffisant pour garantir sa validité.

Pour tester, le tout est d'avoir des tests, et de les lancer dans un fork.
Cela tombe bien car :

• dans un TDD, on a déjà les tests ;
• ceci permet à la moindre personne voulant faire sa propre implémentation de vérifier sa validité ;
• ceci permet aussi d'avoir des exemples d'utilisation du plugins (~ un début de doc) ;
• il n'y a plus de soucis de versions de la bibliothèque, soit elle passe les tests, soit elle ne les passe pas.

Cela veut donc dire que lors de la création de l'interface, je créé les tests en même temps et je les distribue ensembles.
Par contre :

• pour les distribuer ensemble, il faudrait les regrouper au sein d'un même fichier/archive, donc c'est une chose laquelle je dois réfléchir ;
• tester la validité est une chose un peu longue, donc peut-être conserver une paire de hash (testeur, testé) dans un fichier de configuration (?) ;
• l'utilisateur pourra déterminer quels tests la bibliothèque doit valider pour pouvoir être utilisé, ie activer/désactiver certains tests ;

Il faut que je continue à réfléchir un peu.

[bacelar]

Heu, tu trouves que ta solution est simple et la mienne compliquée ???

Moi, je te propose:
Exporter une et une seule fonction en C, qui prend en paramètre un GUID correspondant à la classe demandé et qui retourne une VTABLE avec comme première méthode "QueryInterface" ( http://msdn.microsoft.com/fr-fr/libr...(v=vs.85).aspx ) qui permet de gérer le polymorphisme et les petits blagueurs.

C'est tout.

Si tu veux pas d'une ABI, ça se gère juste avec de l'héritage d'une interface mère de toutes les autres interfaces et un mécanisme d'enregistrement classe<->GUID, c'est tout.

[Neckara]

et qui retourne une VTABLE.

Je n'ai pas souvenir que les V-tables du C++ soient normalisées.

[bacelar]

Je n'ai pas souvenir que les V-tables du C++ soient normalisées.

Pas la peine que cela soit normalisés.
Quasiment tous les compilateurs les font de la même manière pour une plateforme donnée.
Vous prenez ce format et pour les compilateurs exotiques => Todo List.
C'est largement plus extensible que le mangling non documenté.

[Neckara]

Je pense que je vais plutôt partir sur ma seconde solution, mais je continue encore à réfléchir.

On a donc une interface qui est implémentée par un module (plugin/bibliothèque dynamique) et utilisée par un utilisateur.

L'interface est définie par un ensemble de fichiers d'en-tête contenant des classes virtuelles pures.
Par contre, un module ne doit pas uniquement se contenter de respecter l'interface, mais dois aussi respecter le comportement attendu (dont pré et postconditions).

C'est pour cela que je penses à regrouper tous les tests dans une fonction inline dans l'interface.
Donc je suivrais un TDD.

Un module devra alors fournir 2 symboles :

• create_interface_name : retourne un pointeur (dont le type dépend de l'interface implémentée)
• check_interface_name_dependancies : qui va déclarer à l'exécutable ses dépendances (ie les autres modules dont le module actuel dépend).
  Si l'exécutable ne connaissais pas une dépendance, lance toutes les fonctions de tests de la dépendance et l'enregistre.
• info : je pense à une structure contenant des informations (ex. Auteur, date, version, etc.).

J'ai besoin de deux symboles différents car :

• si je force la vérification avant de donner le moindre pointeur, je peux avoir des dépendances cycliques pour les tests ;
• la création de l'instance pointée par le pointeur peut nécessiter une dépendances, donc il faut que j'ai la possibilité de lancer les tests avant.

Après, il est possible de désactiver/activer des tests en jouant avec les macro préprocesseur (ce qui est plus que normal pour des tests).
Et vu que les tests sont des fonctions inlines, si elles ne sont pas utilisées, elle ne coûtent qu'en temps de compilation (ce qui doit rester négligeable je pense).


L'idée se résume donc en quelques mots : "Ajouter les tests dans l'interface".
Grâce aux fonctions de tests, je peux aussi avoir des messages d'erreurs très explicites sur le(s) problème(s) rencontré(s).