[création lib + header pré-compilé]

Bonsoir à toutes et à tous,

Voila je suis en train de coder en ensemble de fonctions et je souhaiterais que cet ensemble de fonctions constituent une librairie utilisable dans plusieurs projets (éventuellement).
Je souhaiterais que le code de cette librairie soit attaché et inclu dans les applications qui s'en serviront, et par conséquent je compte me tourner vers la création d'une librairie statique qui sera liée avec mes projets futurs.

Voila, alors j'arrive à créer A.h et A.cpp qui forment ma bibliotheque.
Je compile ceci et j'obtiens A.lib
Je crée alors B.cpp qui représente le projet qui doit utiliser ma librairie fraichement crée.

Ce que je fais actuellement ensuite :
-------------------------------------
J'ajoute au projet B le fichier A.h qui est le header de ma librairie, et j'ajoute dans visual c++ (onglet "Add to project") A.lib
J'utilise alors les fonctions implémentés dans mal lib.
Je compile. Ca link bien l'ensemble, pas de souci; et mes fonctions sont opérationnelles.
Ma lib fonctionne bien.

Ce que je voudrais faire :
--------------------------
Exactement la meme chose, créer une lib A.lib et m'en servir d'un un projet B mais je voudrais ne pas avoir besoin de fournir le header A.h.
Alors j'ai vu avec visual c++ que quand je demande la création d'un nouveau projet de type "librairie statique windows"; il me propose si je veux "Pre-compiled header"

Et je pense que ça doit être ça qu'il me faut, puisque je voudrais que le header A.h soit pré-compilé; et ainsi je pourrais me servir de la lib A en ajoutant A.lib et A.trucprécompilé (je crois que c'est A.pch) sans avoir besoin de rajouter A.h

En clair je voudrais que la structure de ma lib soit totalement "fermée" et que de l'exterieur tout ne soit que binaire deja compilé pres à etre linké à un projet.

Pourquoi ?
Simplement car je souhaite fournir cette application à quelqu'un et je ne désire pas (encore) présenter la structure de ma lib (donc meme pas le .h).

Bien sur pour que la personne saches ce que contient cette lib je serais obligé d'écrire une doc très complete mais c'est de toute facon ce que j'ai prévu de faire.

Bref, est-ce possible de faire ce que je veux, c'est à dire faire en sorte que ma lib ET son header soit "invisibles" pour l'application qui utilise cette dite lib ?

Voila je suis désolé si je n'ai pas été très clair, mais je peux re-expliquer si je me suis mal exprimé.

nb : Bien sur je simplifie au max le probleme, je n'ai pas qu'un seul header ni qu'une seule source mais le probleme est équivalent à cela.

Je vous remercie d'avance.

ps : je ne suis pas un expert du processus de linkage et de la création de librairie statique; donc essayez si vous pouvez de m'expliquer ca doucement, sans trop trop de termes trop techniques... merki
(et sur google bien sur je n'ai jamais réussi à trouver mon bonheur...)

Non, tu ne peut pas faire ça.

Le header précompilé sers à accélérer la compilation d'un programme mais n'a pas de rapport avec ton problème. D'autre part, pour compiler une application qui utilise des fonctions, ces fonctions doivent être déclarer quelque part. C'est le role de A.h.

De plus, A.h n'est pas censé contenir plus d'information qu'il n'y en aurait dans ta documentation très complète. Si ce n'est pas le cas, c'est que tu as du faire une erreur de conception.

Moralité, laisse dans A.h uniquement les déclaration dont a besoin l'utilisateur de ta lib (de toute manière il *doit* connaitre les prototypes des fonctions de ta lib pour pouvoir s'en servir(si tu ne donne pas de fichier d'en tête il devra les réécrire depuis la documentation, autant lui donner directement les prototype dans le fichier d'en tête, c'est plus sympa)) et rien de plus. Fournit une documentation avec et si nécessaire utilise un fichier d'en tête tel que A_private.h (ou le nom que tu veux) qui sera inclu par A.cpp mais qui n'est pas nécessaire pour utiliser ta lib et ne le distribue pas.

Si ça ne te vas pas, tu dois faire une erreur de conception sur ce que tu mets dans ton fichier d'en tête. poste le sur rafb.net/paste (après en avoir enlevé tes information secrète bien sûr...) pour qu'on te dise ce qui ne devrait pas y être.

merci beaucoup pour ta réponse dnoob.

Non il n'y a rien de secret(et ca ne me dérangerais pas de poster mon code si je l'avais sous la main, je ne suis pas chez moi ce soir) mais c'est vrai que j'aurais préféré éviter de rendre publique les details de conception.

Mais ta phrase " Fournit une documentation avec et si nécessaire utilise un fichier d'en tête tel que A_private.h (ou le nom que tu veux) qui sera inclu par A.cpp mais qui n'est pas nécessaire pour utiliser ta lib et ne le distribue pas" m'a bien faite réflechir : effectivement, pas besoin de fournir les .h qui représentent ma structure, juste les prototyes des fonctions, donc en fin de compte pas plus d'information que la documentation que je dois réaliser comme tu le faisais remarquer à juste titre.

Cependant, j'ai alors une question :

mes .h de ma lib contiennent des classes; et ces classes doivent pouvoir etre utilisés par l'application B (car elle doit utiliser ma lib A).
Et en fait je trouve que donner l'agencement des classes c'est livrer la totalité de la conception de la lib (si ce n'est que les fonctions ne sont pas écrites, mais la structure de la lib est là); et je me demande donc comment est-ce que je peux ne livrer que des prototypes sachant que je n'ai que très peu de fonctions isolées (qui n'appartienent pas à une classe).
90% de mes fonctions sont des données publiques de mes classes.

Je dois donc donner le .h qui contient toutes mes classes...

1) Alors comment faire ? Mettre mes classes dans les .c et non plus dans les .h ?
2) Ecrire une version de mes .h "allégée" qui ne contiennent que des prototypes, et pas les classes; mais alors comment fera l'appli B pour utiliser des instances des classes de ma lib A ?

Je ne suis pas contre le fait de livrer juste des prototypes en fait, tu as entièrement raison la dessus, c'est debile de laisser le programmeur utilisant ma lib les ré-écrire depuis ma doc.

Mais alors, comment est-ce que je masque les details de conception moi ?

En tout cas merci pour ta réponse qui m'a faite réfléchir; meme si du coup je me pose encore plein de nouvelles questions.

pour les classes, c'est comme les fonctions :

Soit le programmeur qui utilise ta lib ne les utilise pas, elles sont juste nécessaire pour faire tourner des fonctions auxquelles le programmur a accès. Dans ce cas là ne les mets pass dans ton fichier d'en tête publique.

Soit le programmeur les utilise alors là aussi il a besoin d'avoir accès à la déclaration de la classe.

Mais peut-être que tu ne sais pas que l'on peut séparer la déclaration et la définition d'une classe (j'en ai l'impression en lisant ton message).

Dans A.h tu mets :

class A
{
public:
A();
A(int i);
int f();
void g(double d);

private:
int a,b,c;
};

et dans A.cpp, tu mets :

A::A()
{
a = b = c =0;
}

A::A(int i)
{
a = i;
b = c = 0;
}

int f()
{
return a;
}

void g(double d)
{
c = (int)d;
}

exemple stupide comme un autre, mais tu peut séparer les deux. Le programmeur n'a plus accès à l'implémentation de la classe.

La différence c'est que généralement (mais ça dépend du compilo et ce n'est pas du tout aussi simple que ça) les fonctions de la classe ne seront pas inliné avec cette deuxième méthode contrairement à la première (où c'est une possibilité qu'elle le soit).

Mais croire que c'est une source importante de perte de performance est une erreur (sauf dans quelques cas critique).

oui dnoob, je sais que l'on peut séparer la déclaration de la définition d'une classe et c'est exactement comme ca que je procede en fait

Okay donc en fait pas d'autre choix que de livrer l'ensemble des .h qui continnent la déclaration de tout ce dont l'utilisateur va utiliser (classes, fonctions ... etc)

Mais alors du coup, si l'utilisateur de ma lib A qui crée son projet B a besoin de créer des instances de ManagementA (une classe), et que cette classe est définie ainsi ;

//A.h
class ManagementA
{
private :
int a, b, c;
AuxiliaireB aux; // une instance d'une autre classe définie dans le lib
//...

public :

ManagementA(); ~Management();

}

Donc le créateur de B veut utiliser cette classe (ie en créer des instances), faut il alors que je lui livre aussi le header qui déclare la classe AuxiliaireB ?

En y reflechissant, la réponse que j'aporterais est oui.
Car quand il va compiler ses sources avec ma lib et mon .h; son compilo va gueller et pas comprendre qu'elle est cette classe AuxiliaireB.

Donc il faut que je lui fournisse toutes les déclarations dont il a besoin, + celles qui déclarent les objets contenue dans les précédentes déclarations.

Bon bah dans mon cas (mon moteur 3D), il faudra que je livre alors quasimment tous les header de l'appli. Est-ce un probleme de conception ?

En y reflechissant je pense pas trop car justement le but de mon moteur 3D est d'offrir des interfaces qui permettent de gérer des objets3D, des lumières, etc... donc en fin de compte devoir lui livrer les déclarations de ces objets là semble asser normal.

Qu'en penses tu ?
Y a t-il une grande probabilité que j'ai fais une grande erreur de conception ?

Perso vous quand vous developpez une lib, grosso modo les headers que vous devez fournir, c'est 60% de l'ensemble des headers de l'appli ? 80%, 90% ?

Encore merci pour ta réponse dnoob.

désolé j'ai fais une erreur dans l'exemple à la con que j'ai décris : ma fonction auxiliaireB est en fait auxiliaireA (car elle est définie et implémentée dans ma lib A).

si dans ta classe A tu ne mets pas un "auxiliaireA aux" mais un "auxiliaireA* aux" (ou une référence, peut-être aussi, je n'en suis pas sûr) alors tu peut réduire la déclaration de auxiliaireA à juste une seule ligne dans A.h

du genre :
class auxiliaireA;

Et tu as un autre fichier auxiliaireA.h qui est inclue par A.cpp après A.h qui contient la vraie déclaration de la classe.

Bien sûr l'utilisateur ne pourra pas accéder aux membres de auxiliaireA ni créer d'instance de cette classe, mais je suppose que c'est ce que tu veux.

ok merci donc avec un pointeur dans l'objet pas besoin de livrer l'interface de l'objet pointé en plus.
Donc je vais poter pour cette methode là quand il y aura des details de conception que je ne veux pas livrer (à l'heure actuelle dans mes objets je mettais des instances d'objet et pas des pointeurs)
Merki beaucoup pour toutes ces précisions dnoob, c'est très sympa.

de rien.

J'en profite pour rajouter que sauf si tu as une raison bien précise d'utiliser VC6, tu devrais passer à VC 2005 qui est gratuit dans sa version express. Et même si l'interface de la version express est réduite par rapport à visual studio, l'interface de VS98 est suffisement ancienne pour que tu y gagne quand même.

D'autre part, VC++6 a de très grosse lacune sur le C++ (la première norme du langage n'est sortie qu'en 98 même si les spécification était déjà connue) particulièrement sur la couche objet.

Ton code ne sera pas portable, des exemples de sites web ne fonctionneront pas et tu vas perdre tes cheveux (enfin ça, c'est pas sur).

Bref, je te recommande de changer de version (VC8 par contre est l'un des compilo les plus respectueux de la norme).

en fait c'est un peu idiot mais je me suis tellement habitué à VC6 que j'ai du mal à m'en détacher.
Il faudrait que je m'installe la version 2005, tu as raison.

Bon en plus j'imagine que l'interface doit etre à peu de chose près inchangée, avec peu etre qq fonctionnalités en moins.

Alors du coup : question : si j'installe VC 2005 express, y'a pas de soucis si je concerve en plus ma version 6 ?
Je veux dire le nouveau dossier va pas me foutre le bazar dans mon ancien environnement de dev ?

Car comme j'aimerais bien y passer en douceur j'envisage de faire cohabiter les deux version un petit bout de temps sur mon pc.
voilou, bonne soirée dnoob

non, il doit pas y avoir trop de problème. Faut juste regarder ce qui arrive aux variables d'environnements, mais je pense que VC2005 les définit lui même donc il n'est pas affecté par les réglages de VC6.

Par contre, attend toi à trouver bcp de nouvelles fonctionnalité dans VC2005.

Au fait, il n'y a qu'un seul 'o' dans mon pseudo ...