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.

[djuju]

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.

[yann458]

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.

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 ?

[bacelar]

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.