Version imprimable
Bonjour,
Dans Visual Studio Je voudrais dans un .lib (librarie statique ) appeler (ou equivalent de linker) une fonction d'une autre .lib , mais en mode
inline c'est à dire faire l'équivalence de "__forceinline", c'est à dire le compilateur
incorpore à répetition le contenue de la fonction de l'autre .lib autant de fois que je l'appelle.
Est - ce possible ?
J'en aie besoin.
Info : Les fonctions déclaré en inline definit dans une librarie statique ne sont pas exportable.
Merci beaucoup
salut
comme tu le dis toi-même : inline est lié au compilateur.
je ne vois pas comment le linker pourrait faire ce boulot.
C'est théoriquement réalisable avec des outils dédiés ou en traficotant les outils d'optimisation globale de VS, mais c'est éminemment complexe et vraiment fragile comme approche.
Je suis très circonspect sur le bien fondé d'une telle approche.
Normalement, les fonctions "inlinables" systématiquement sont facilement convertible en MACRO et cela ne pose pas de problème dans ce cas de les mettre directement dans les fichiers d'header de la lib.
J'ai un projet (a.lib) qui met 5 minutes à compiler ,
cl.exe met enorme de temps à compiler car c'est un projet spéciale ,
et je voudrais dans un autre (b.lib) que le compilateur recopie les code d'une fonction nommé "mafuncdea" du projet (a.lib) autant de fois que j'appelle la fonction "mafuncdea" dans le projet (b.lib) definit dans le projet (a.lib).
voilà ;
J'ai travaillé sur des projets dont la compilation complète du projet prenait 8 heures sur un octo-pro et de la RAM à foisons et 1h30 au minimum, avant que je ne fasse un découpage par Dll, cela relative votre " enorme de temps". :aie:Citation:
J'ai un projet (a.lib) qui met 5 minutes à compiler ,
cl.exe met enorme de temps à compiler car c'est un projet spéciale ,
Pourquoi ne pas en faire une MACRO ?
Pourquoi ne pas faire un projet de lib spécifique ?
Pourquoi le code source de cette fonction n'est pas transférer du projet a.lin au projet b.lib ?
Vous ne donnez pas assez de détails pour justifier d'une approche aussi peu orthodoxe.
En faites , il s'agit de licences numérique pour mes applications / utilitaires que je vend ,et je fais en sorte pour décourager le crackeur( pirate).Citation:
Envoyé par bacelar
Mon idée :
un .lib (a.lib) qui gére le decodage de mes licence qui met un plomb à compiler
un .lib (b.lib) qui gére l'affichage d'information utilisateur et les droits d'utilisation de telle fonction(s) de mes applications.
Pour gagner du temps à chaque modification de la lib b.lib ,c'est inliner la fonction de decodage de licence depuis le lib "a.lib" ,c'est la meilleur solution car si pas inliner il suffit que le crackeur remplace l'instruction d'appelle "CALL" par une autre fonction et le tour est jouer.
Pour le moment tout est dans le même .lib.
Salut,
Comme l'a dit fregolo52, l'inlining est une fonction du compilateur et non du linker. Tu ne peux donc pas inliner tes fonctions à l'extérieur de ta lib en fournissant seulement le header.
Par contre, tu peux implémenter directement ta fonction dans le .h et ça marchera puisque ta fonction sera inlinée une fois à la compil de a et une autre à la compil de b.
Ce que je ne comprend pas, c'est ce que tu veux distribuer. Est-ce :
- Les lib statiques a et b
- Une lib statique c qui serait un link de a et b
- Un exe à partir de a et b
- Une DLL à partir de a et b
Si tu distribues une lib c, un exe ou une DLL, pas de pb les calls à a ne pourront pas être remplacés comme ça.
Pour a et b, je vois pas trop pourquoi tu voudrais faire ça.
Je distribue l'exe ou la dll utilisant la lib b.Citation:
Envoyé par djuju
Mais tanpis je ferai que sur un seule .lib qui utilise les header h mais pas les macros.
Peux être faire ce genre chose avec l'intrinsic ?
Je ne comprends pas pourquoi vous ne voulez pas utiliser de MACRO.
C'est l'un des seuls cas ou cela se justifie pleinement ?
Avec les macros, dans un .h, vous avez plus de problème, non ?
Pas lib et pas de call.
Ce n'est pas le top pour la compatibilité inter-compilation ou la maintenance mais faut faire des compromis.