Discussion :

[JaroBx]

Bonjour à tous,

Je reprends un projet et j'ai trouvé quelque chose de dégueulasse !
Il y a une librairie statique qui est crée (.lib). D'après l'utilisation classique d'une librairie statique, on devrait linker sur cette librairie statique ainsi que inclure son .h.
Or dans le projet que j'ai repris, on link bien sur la librairie static (.lib) mais le .h inclus n'est pas le même que celui avec lequel la librairie en elle même a été compilée.


Exemple de différence :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
Vrai ".h" :                             Mauvais ".h":
struct a                               struct a
enum b
struct c
struct d                               struct d
fonction e                            fonction e

Certaines définitions ont été mises en commentaire (enum b et struct c de l'exemple). A la compilation de mon projet je n'ai pas d'erreur. Par contre l'application a un comportement bizarre, comme des problèmes d'alignements.
Je vais refaire l’inclusion de la lib de manière propre car je ne pense pas qu'il soit normal de travailler comme ça.
Je voulais juste connaitre les risques de cette absurdité, pouvez-vous m'aider ? Risque-t-on d'avoir des problèmes d’alignements avec ça ?

Merci !
Bonne journée

[mala92]

salut,

si je comprends bien tu as un ".h" lite pour l'utilisation de la lib. c'est en effet pas très beau, mais ça ne doit pas générer des problèmes d'alignement.

C'est sûrement ta lib et ton appli qui ne sont pas compilées avec le même type d'alignement.

[JaroBx]

Merci pour ta réponse.

Tu as bien compris le problème.
La lib et le projet sont compilés avec le même alignement, mais l'utilisation de certaines fonctions de la lib ont des effets sur des variables qui n'ont rien à voir. Du coup tout est foireux au final.
Je pensais que le fait d'utiliser un ".h" lite pose problème

[Bousk]

Bonjour,

proposer un header différent ne me choque pas.
La lib a son propre header qu'elle n'utilise qu'en interne et a choisi d'exposer un second header qui est celui sur lequel un utilisateur doit se baser pour utiliser cette lib.

Dans tous les cas, je ne vois pas pourquoi il y aurait un problème d'alignement s'ils sont cohérents.

[JaroBx]

Merci à vous deux pour vos réponses !
Je trouvais juste bizarre qu'une même librairie puisse être utilisée avec des header différents.

[Bousk]

Il n'y a qu'à voir le header C de FILE.
Il y a sûrement un autre header qui définit clairement la structure FILE et ce qu'elle contient, qui est invisible à l'utilisateur qui n'utilise que FILE* et les méthodes fournies.

[koala01]

Salut,

En, fait, tant que le fichier d'en-tête "lite" n'expose ni structure ni fonction qui aurait besoin des structures manquante, il n'y aura strictement aucun problème.

On peut considérer qu'il s'agit d'une "encapsulation" à l'ancienne (un peu comme ce qui se fait pour FILE, comme l'a signalé Bousk)

En travaillant de la sorte, tu en arrive au résultat que l'utlisateur ne peut utiliser que certaines structures et certaines fonctions, et donc, cela revient à considérer que les fonctions et structures manquantes font partie des "détails d'implémentation" et de la "popote interne" de la bibliothèque

[JaroBx]

Merci à vous, j'aurais préféré une réponse du style : "Interdit de faire ça, si tu changes tout va fonctionner"

J'ai appris quelque chose

[koala01]

Merci à vous, j'aurais préféré une réponse du style : "Interdit de faire ça, si tu changes tout va fonctionner"

Je te comprend parce que cela t'oblige à investiguer, tant au niveau du programme lui meme qu'au niveau de la bibliothèque, pour arriver à comprendre ce qui se passe et "pourquoi ca coince"

J'ai appris quelque chose

Pour fixer complètement les choses, j'ai l'impression qu'une petite explication sur les fichiers d'en-tête s'impose

Il faut comprendre qu'un compilateur va "lire" un fichier du début à la fin, exactement comme toi, tu lirais le dernier roman de Stephen King, et qu'il oublie, quand il a fini de traiter un fichier, tout ce qu'il pouvait contenir.

Quand tu es à la page 15 du roman, tu sais ce qui s'est passé durant les 14 premières pages, mais tu ne sais absolument pas ce qui va se passer à la page 16 (à moins qu'on ne t'ait raconté l'histoire )...

Pour le compilateur, c'est pareil : quand il est à la ligne 10, il ne "connait" que ce qui se trouvait dans les lignes précédentes mais n'a strictement aucune connaissance de ce qui se trouve aux lignes suivantes

Et, comme le compilateur est un imbécile buté, s'il rencontre un "identifiant" (on parle normalement de symbole ) qu'il ne connait pas (parce qu'on ne lui a pas encore dit, au minimum que le symbole existe), il va s'arrêter et t'injurier en t'expliquant qu'il ne connait pas le symbole en question.

En fonction des situations, ce que le compilateur :

• Quand on utilise un pointeur ou une référence : il peut se contenter savoir que le type existe (tant que l'on n'essaye pas d'accéder à l'un des membre du type en question)
• Quand il s'agit d'utiliser un type (comprend : d'accéder à un membre ou à une fonction membre), il doit savoir ce que contient le type (tous les membres (type et identifiant) et les fonctions membres, ainsi que les éventuelles relations d'héritage) pour pouvoir s'assurer que le membre ou la fonction auquel (à laquelle) on essaye d'accéder existe
• Quand il s'agit d'utiliser une fonction (éventuellement membre d'une classe ou d'une structure), il doit en connaitre le prototype ( type de retour + nom + type et nombre des arguments) de la fonction pour pouvoir s'assurer que l'on transmet les bons types d'arguments au bon moment et que l'on récupère (éventuellement) le retour de la fonction dans un type correct

Un fichier d'en-tête permet au compilateur :

• de savoir qu'un type existe lorsque l'on fait une déclaration anticipée (ce qui permet au compilateur de ne pas s'inquiéter de trouver le type en question dans les éventuelles fonctions, tant que c'est sous la forme d'un pointeur ou d'une référence)
• de savoir ce que contient un type quand il s'agit d'une définition du type en question
• de savoir le nom de, le nombre et le type des arguments et le type éventuel de la valeur de retour des fonctions

Bref, tout ce qu'il faut pour qu'il soit content

En effet, avant que le compilateur ne prenne la main, il y a un outil que l'on appelle "préprocesseur" qui passe par là, et qui va (entre autre) remplacer toutes les directives #include <unfichier> et toutes les directives #include "unfichier" par... le contenu du fichier en question.

La "bonne pratique" consiste à ne mettre dans un fichier d'en-tête que le stricte minimum qui "travaille de concert" pour que cela ait un sens.

En effet, tu pourrais très bien placer dans un seul et meme fichier d'en-tête l'ensemble des fonctions et structures pour faire de la trigonométrie ( sin, cos, tg, ...), pour gérer les dates, pour gérer les heures et pour gérer les ages du capitaine.

Mais on peut décemment se dire que, quand tu vas devoir utiliser les fonctions de trigonométrie, tu t'en fouteras sans doute pas mal d'être en mesure de travailler sur des dates, des heures ou sur l'age du capitaine

De plus, il faut savoir que, si tu décides de rajouter une fonction pour le traitement des dates, meme les fichiers qui n'utilisent que les fonctions de trigonométrie ou de gestion de l'age du capitaine devront être recompilés, et les temps de compilation ont déjà tendance à suffisamment s'envoler comme cela

La "bonne pratique" consiste donc à mettre, dans un fichier d'en-tête, uniquement les fonctions de trigonométrie, dans un autre, uniquement les fonctions (et les structures) nécessaires à la gestion des dates et dans un troisième uniquement les fonctions (et les structures) nécessaires à la gestion de l'age du capitaine.

De cette manière, si tu dois manipuler un peu de dates et un peu l'age du capitaine dans un fichier (car cela arrive, mais assez rarement, du moins on peut le penser ), il te "suffit" d'inclure les deux fichiers d'en-tête correspondant.

Mais, à coté de cela, si la gestion de l'age du capitaine fait partie de "la popote interne" d'une bibliothèque, que l'utilisateur "normal" de cette bibliothèque n'a absolument pas besoin de savoir que la bibliothèque gère, en interne, l'age du capitaine, il n'y a strictement aucune raison de fournir le fichier d'en-tete qui parle de la gestion de l'age du capitaine : son utilisation peut etre totalement opaque pour l'utilisateur final

Dans le cas présent, celui qui a mis la bibliothèque au point a, de toutes évidences, suivi un raisonnement similaire, meme si l'on peut regretter la manière dont il s'y est pris.

Personnellement, j'aurais sans doute créé (et fourni ) le fichier "lite" d'un coté, et j'aurais créé (et gardé pour un usage interne) un autre fichier contenant les fonctions et les structures "à usage interne uniquement"

[JaroBx]

Merci de t'être donné la peine d'écrire tout ça
Je vais devoir investiguer dans totalement autre chose. Au moins, j'ai pas trop perdu de temps sur une fausse piste !

[3DArchi]

Salut,

La différence des fichiers d'en-têtes reste malgré tout quelque chose de bancale. La compilation de la bibliothèque pourrait s'appuyer sur le .h exporté, ce serait - risqué.

Ceci dit, pour ton problème, deux questions importantes :
-> c'est du C ou du C++ ?
-> quel(s) est/sont le ou les compilateurs utiliser pour la bibliothèque et pour son client ?
-> quels sont les options de compilation utilisées ?