Reprise du message précédent :

 
Et bien je définit les prototypes des fonctions qui se trouvent dans fille1.c
C'est bien ça qu'il faut faire non ?

non je te parle de ta commande #define
qui ne definit rien:
remplace #define
par #define _fille1_h
 
LeGreg

 
salut,
 
oooops oui c'est une grossière erreur d'inattention excuse moi LeGreg
Mais sinon c'est quel(s) fichier(s) que je dois compiler pour la librairie ?
Chaque .c (base.c et fille1.c, fille2.c, etc...) ?
Bon ya de l'orage, je me déconnecte
 
@++

Voilà une de mes grandes interrogations:
Si le code n'est pas chargé toujours à la même adresse, comment gère-t'on les sauts au niveau processeur ?
Il me semble que l'architecture Intel dispose de registres d'adresses de base et d'automatismes pour décaler les adresses.
Mais c'est comme le mécanisme de mémoire virtuel: Ça a forcémment un coût à l'exécution.
 
 

Voui.
J'aimerais un moyen portable d'éviter ce préhistorisme.

Les sources ne devraient pas aller dans un répertoire d'includes.
 

A ce que les utilisateurs externes à la compilation connaissent les noms et formes de ce qui s'y trouve.
A partager les informations communes.
Si tu mets tout dans le .c, un autre source devrait faire les déclarations pour pouvoir faire les appels.
Alors autant les écrires une seule fois dans un header et les patgager.
 
 
J'aurais plutôt mis:
fille1.c:

fille1.h:

 
utilisateur.c ou .h

Masuran,
 
Salut,
 
Merci
 
Déjà je précise il s'agit de c++ et non de C. Je crois pas que ça change grand chose (mais je
me trompe peut-être). base.cpp contient la classe de base, les fichiers filleN.cpp les classes filles.
J'ai fait exactement comme tu viens de dire, mais j'ai malgré tout des erreurs de redéfinition,
je vais t'expliquer.
Je veux créer une librairie dynamique, voilà le script que j'exécute :
 

 
Sachant que :
* Chaque filleN.h contient plus ou moins :

* Le fichier base.h contient juste les include standard (stdio.h, ...)
 
*Chaque fichier filleN.cpp contient #include "filleN.h"
*Le fichier base.cpp contient #include "base.h"
 
 
Jusque là pas de problème, ma librairie est créée
 
PROBLEME 1 :
------------
fille2.cpp contient des fonctions qui appellent celles de fille1.cpp
Mais si, dans fille2.h, je fais #include "fille1.h" (voir fille1.cpp, ça change rien) en plus du
#include "base.h", j'ai des erreurs de redéfinitions de fonctions de base.cpp
 
PROBLEME 2 :
------------
Dans le même dossier, j'ai l'applications principale "main.cpp" qui contient tous les
#include des fichiers filleN.h, j'ai aussi les même problèmes de redéfinitions que
précédemment, au niveau de fille2.h cette fois-ci.
Si j'enlève fille2.h, c'est au niveau de fille3.h, et ainsi de suite.
Autrement dit il inclus fille1.h, mais pas les suivants (à cause des redéfinitions) !
 
PROBLEME 3 :
------------
Si en bidouillant beaucoup (mais c'est pas viable) je n'ai plus d'erreurs, et que j'arrive
à créer la librairie, c'est super.
Dans le dossier j'ai un fichier libtoto.so.1.0
Mais je ne sais pas du tout quoi en faire pour l'utiliser. Je créé un lien dans /usr/lib
vers ce fichier, mais ensuite comment l'utiliser ?
Utiliser -ltoto dans les arguments de g++ ?
 
Merci à vous

Ils sont gérés par des sauts donnés en adresses relatives, la plupart des architectures gèrent ça directement.
Mais le problème avec les PC, c'est, si j'ai bien compris, qu'ils ne gèrent pas lesdites adresses relatives, il faut donc calculer l'adresse à chaque saut avec une addition. C'est là le gros inconvénient des bibliothèques dynamiques...

Reprenons : il ne faut jamais jamais jamais inclure de fichiers de code avec les #include, ni dans les .c(pp), ni dans les .h.
 
S'il y a des erreurs quand tu inclus 2 fois le même fichier, c'est que tes #ifnedf _MACHIN_H ne sont pas bien faits.
 

Tu as du t'emmêler les pinceaux quelque part. De toute façon, si base.h appelle tous les autres .h, tu n'as plus besoin de les inclure nulle part.
 

Un premier truc, dans la génération de ta bibliothèque, c'est -Wl,-soname,libtoto.so.1 qu'il faut mettre, pas -Wl,-soname,libtoto.so
 
Ensuite, il faut copier le ou les .h que tu vas utiliser dans ton programme vers /usr/local/include (on ne touche PAS à /usr, juste à /usr/local !).
Puis tu mets le libtoto.so.1.0 dans /usr/local/lib, avec des liens en chaîne : libtoto.so -> libtoto.so.1 -> libtoto.so.1.0
Pour compiler, c'est -ltoto.
 
Explication des liens : quand on compile avec -ltoto, il va chercher libtoto.so, qui est un lien vers la version courante. Au lancement du programme, il va chercher le SONAME donné par l'option de compilation de ta bibliothèque (-Wl,-soname,...), donc il faut que ce SONAME soit libtoto.so.1, car si jamais tu fais des changements incompatibles dans ta bibliothèque, tu l'appelleras libtoto.so.2. Ainsi les nouveaux logiciels l'utilisant seront compilés avec le plus récent grâce au lien libtoto.so mais les anciens logiciels compilés avec la première version continueront de marcher.

As-tu protégé base.h ?
d'après les symptômes, je ne pense pas.
 
Un header doit être protégé s'il va être inclus plisieurs fois dans une même compilation, y compris indirectement:

En pratique, on les protèges toujours.
 
Si c'est pas ça, c'est qu'il y a une élément illégitime dans tes headers, voir ma 'white-list' plus haut.

 
le probleme d'inclusion des headers est effectivement lié au C, pour avoir quelque chose de moins archaique, je te suggere de changer de langage. java est cool de ce point de vue la, delphi l'est aussi mais un peu moins (a cause du compilateur qui n'agit qu'en une seule passe..)
 
Je crois que dans certaines boites on arrive a faire un seul gros fichier .cpp par librairie avec un outil spécial qui preprocesse les fichiers du projet. (ca peut accelerer la compilation aussi). Par contre ca represente quelques concessions au niveau du code.
 
LeGreg

Tant pis, je préfères encore rester au C++.
 
A mon sens une bonne compilation devrait se faire en 4 étapes:
1a) Compilation texte->langage.
1b) Optimisation au niveau langage.
2a) Compilation langage->instructions machine.
2b) Optimisation au niveau machine.
 
2a/2b pouvant être fait au dernier moment, par la machine devant éxécuter le programme.
 
Par contre, une compilation devrait être monolithique.
Je veux dire que le passage inutile par des morceaux objet intermédiare gêne certaines optimisations.
 
En ce sens, je comprends qu'on puisse tricher et faire des #include de sources bien conçus pour simuler un seul gros source.

 
ce que tu decris c'est ce qui sous-tend je crois la conception des langages compilés modernes (java jitte, CSharp), avec en plus le souci de la portabilité.  
 

 
La compilation monolithique ca marche effectivement bien avec le principe d'executables monolithiques, livrables tels quels. Par contre c'est clair qu'on se traine les objets du C par souci de compatibilité, alors qu'on aurait la possibilité de faire mieux sans doute (comme souvent en informatique).
 
LeGreg

On pense aux mêmes choses visiblement.
 
Vu que C et C++ sont très orientés performance, je suis étonné qu'on traîne encore de tels boulets.
 
Juju, as-tu résolu ton problème ?

 
ce que vous m'avez dit m'a pas mal aidé, mais je n'ai pas résolu à 100 % (encore un problème).
Enfin un mini bidouillage et ça marche (sans être optimisé au mieux).
 
Mais le problème vient de moi, je n'ai pas assez étudié le C, je sais je suis fautif
enfin bon, je me suis trop intéressé au C++ sans apprendre A FOND le C (ça se voit d'ailleurs), mais je vais réparer cette erreur.
 
Merci, @++

Faut pas aller trop A FOND en C.
 
Souvent le C++ donne de bonnes alternatives.
 
Bon, pour les #include, y'a rien de mieux   .

Musaran a écrit a écrit : Faut pas aller trop A FOND en C.   Souvent le C++ donne de bonnes alternatives.   Bon, pour les #include, y'a rien de mieux   .

 
Oui bien sûr, mais l'un n'empêche pas l'autre
Je préferais avoir de meilleurs bases en C...
 
Merci, et au w-e prochain !