Classes supprimées lors du link : forcer l'utilisation de classe

Bonjour.

J'ai une application qui link avec des librairies en static.
J'ai donc à la fin, un executable sans DLL.
Le linker fait son travail, c'est à dire qu'il supprime toutes les classes / fonctions qui ne sont pas utilisées. Ceci est normal.

Sauf que... j'utilise un système de sérialisation "maison" basée sur le concept d'archive / Objet serialisable des MFC. En gros, chaque classe contient des informations de runtime permettant d'instancier une classe par son nom (sous forme de chaîne de caractères) et de se serialiser / deserialiser la classe. Le but ? Se passer des classes entre process via des sockets.

Ca fonctionne plutot bien sauf que....
Le serveur instancie la class A puis l'envoi au client. Le client reçoit une donnée puis récupère le nom de la classe, l'instancie dynamiquement, deserialise et on a la classe copie de celle du serveur... sauf que, nulle par dans le code, au niveau du client, il n'y a d'instanciation de la classe A et le linker la supprime... lorsque le système de serialisation tente d'instancier A, il ne trouve pas A et ne peut donc l'instancier.
Seule solution trouvée pour le moment : Créer dans l'executable, une variable globale de A qui ne sert à rien, sauf à instancier A afin que le linker ne supprime pas la classe.
J'ai tenté de faire une variable statique de A dans A, mais c'est idem, la classe A ne fait plus partie de l'EXE une fois linké.

Y a-t-il un moyen plus propre de dire au linker : conserve cette classe dans l'exe au lieu d'instancier une classe qui ne sert à rien ? Via un pragma par exemple.
J'utilise wxWidgets / Code::Blocks / MinGW (gcc + gdb). Une solution multi-plateforme / multi compilateur est préférable.

Des idées ?

Bonjour,
J'ai du mal à voir comment tu instancies dynamiquement une classe A ... sans instancier de classe A dans le code ?

Le programme ne fait pas de new A ou d'instanciation de A.
Il demande au RuntimeClass d'instancier la classe qui s'appelle "A".
Ces Runtimes informations sont liées les unes aux autres par des pointeurs, le tout est contenu dans des classes statiques qui ont entre autre le nom de la classe, un pointeur sur la classe mère et un pointeur sur une méthode statique d'instanciation de la classe...

Le projet sur lequel je travail pour Free est disponible via SVN si tu veux y jeter un coup d'eil.
https://cansiport.svn.sourceforge.ne...oot/freeconfig

Ce n'est que le début, pas encore grand chose à voir mais si tu veux voir la façon dont sont créés les objets...
C'est dans CAnsiPort : CAnsiPortObject et CAnsiPortClassInformation.

Pour la création des classes utilisants ce principe, il faut aller voir dans le projet FreeConfigMessages.

La sérialisation utilise CAnsiPortArchive et les classes CAnsiPortFile & CAnsiPortMemFile.

Voila. J'ai toutefois pas la réponse à ma question :P

Salut,
Dans CAnsiPortArchive::ReadObject, il y a bien un CreateCAnsiPortObject qui fait un new CAnsiPortObject ? Ou il y a quelque chose que j'ai loupé ?

Non c'est cela. Sauf que dans le code, il n'y a qu'un new de la classe concernée dans la méthode statique de celle-ci mais cette méthode statique n'est pas appelée directement par mois mais pas un l'algorithme de recherche de classe et de création dynamique.. le linker ne vois donc pas que je vais ce new... et donc il supprime la classe.

Cette fonction statique est bien référencée quelque part ? Tu récupères bien son adresse pour la mettre dans quelque chose qui doit ressembler à un conteneur associatif nom/fonction de création. C'est là que j'ai du mal à voir pourquoi le compilateur décrète que la fonction n'est pas utilisée...
Mais pour répondre concrètement à ton problème, je ne vois pas vraiment de solution en tunant le compilo... Peut être qu'en marquant la fonction comme 'exportable' (comme si c'était une DLL) ? Après, à brûle-pourpoint, je ne vois pas immédiatement d'éventuelles conséquences d'un tel choix.