Discussion :

[yann458]

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

[fregolo52]

salut

comme tu le dis toi-même : inline est lié au compilateur.
je ne vois pas comment le linker pourrait faire ce boulot.

[bacelar]

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.

[yann458]

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à ;

[bacelar]

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 ,

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".

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.

[yann458]

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".

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).

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.