Contourner le dead code stripping

Salut à tous,

J'ai un système qui est basé sur une object factory à laquelle on donne une metaclasse et qui retourne un objet alloué avec le constructeur adéquat.

Mon pb est que si il n'y a aucun appel explicite à un type particulier, tout ce qui le concerne (incluant la metaclass) est dead code strippé.

Pour ce qui est de mon côté, pas de soucis, je fais des dummy calls pour empêcher le dead code stripping. En revanche, un client peut vouloir développer son propre composant. Pour l'instant, je dois lui imposer de faire les mêmes dummy calls que moi, ce qui est loin d'être très propre à mon goût.

Est-ce que quelqu'un aurait une méthode moins sale? (genre un #pragma TouchePasACa)

Merci.

Hum ça me rappelle quelque chose, où justement ce qui paraissait être uen bonne idée (linker avec le .obj qui va bien) était en fait du point de vue du client pas top.
Tu fournis ta lib sous forme de lib statique ?
Tu peux donner un petit exemple du principe de ta factory et ses "metaclasse" ?

Salut,

En fait, voici le concept.

• On a une interface Item dont on fait dériver Apple

• On crée, via une macro, une instance de ItemMetaClass qui va stocker "Apple" en nom de metaclass et Apple::Create() en tant que fonction de création d'Item. La metaclasse s'enregistre dans un conteneur de toutes les metaclasses connues au sein de son contructeur

• En lisant un fichier ASCII de config dans lequel j'ai les noms des items, je récupère dans le conteneur la metaclasse adéquate (par le nom) et j'en extraie la fonction qui me permet d'instancier un Item

Le problème est que, si je ne fais jamais explicitement appel à la metaclass créée pour Apple, elle sera dead code strippée. Or, je ne l'appelle jamais dans ma lib, et du côté du client je ne peux rien garantir.

J'ai trouvé une manière cradissime de faire, mais je ne suis pas satisfait avec ca:

Code:

---

#pragma comment(linker, "/INCLUDE:?Class@CApple@@2VCItemMetaClass@MyNameSpace@@A")

---

En incluant ce pragma dans le header, on force le symbole correspondant au nom décoré à faire partie du link. Le seul truc, c'est que cette syntaxe doit être extrêmement dépendante du compileur et pas du tout cross-plateforme. De plus elle suppose de connaitre lel nom décoré de la métaclasse, ce qui n'est pas évident.

Donc, si tu as d'autres idées, je suis preneur. Merci.[/list]

Oui y'a ce pragma mais je ne l'aime pas non plus pour les mêmes raisons que toi.
Normalement l'optimisation que tu subis n'a pas lieu avec les dll. Les objets statics non référencés ne sont pas éliminés. Ca se produit que avec les libs statiques il me semble.
Tu peux regrouper tes "dummy calls" au sein d'une fonction Init() que ton client appelle. Pour ma part, je me suis pas embêté. Au lieu de passer par le constructeur + les meta classes, j'ai un fichier central d'initialisation de mes factories dans lequel je fait le boulot de tes constructeurs (une grosse fonction Init() quoi). En fonction de la configuration du logiciel, ce fichier enregistre ou non certaines classes dans la factory qui va bien. Ce fichier est dépendant de toutes les classes concernées, mais finalement je trouve ça peut être mieux. Les classes n'ont pas à se soucier d'être enregistrées dans la factory, et la factory ne sait vraiment rien des autres classes.
Y'a juste un 3° acteur (fonction Init() ) qui fait des factory.Add( "Apple", &CreateApple );
Note que cette fonction Init() n'a pas besoin d'inclure "Apple.h", il suffit de déclarer CreateApple(); et d'implémenter cette dernière dans Apple.cpp.
C'est peut être pas le plus élégant, mais moi ça m'a suffit.
J'avais vaguement exploré d'autres voies (exporter CreateApple et faire un GetProcAddress en construisant le nom qui va bien), mais bien que séduisant techniquement, c'est quand même du bricolage.