Discussion :

[olivier_u]

Bonjour,

Pour mon premier message, je pose un débat pour programmateurs confirmés.

Nous sommes un groupe de programmateurs à travailler sur plein de codes utilisant des bibliothèques communes (et donc des fichiers communs). Nous avons, entre autres, un fichier macros.h qui, comme son nom l'indique, concentre les macros très couramment utilisées.

Le débat est le suivant :

Soit un fichier header toto.h :

Code :

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

1
2
3
4
5
6
7
8
9
 
#ifndef _H_TOTO_H_
#define _H_TOTO_H_
 
int fonction1(int a);
 
int fonction2(int a);
 
#endif /* _H_TOTO_H_ */

et son fichier toto.c associé.

Passons au fichier macro.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
#ifndef _H_MACROS_H_
#define _H_MACROS_H_
 
#define SQR(x) ((x) * (x))
 
#define MACRO_1(x) ...
 
#define MACRO_2(x, y) ...
 
#define MACRO_3(x) ...
 
[...]
 
#define MACRO_N(x, y) (fonction1(x) + fonction2(y))
 
#define MACRO_N_PLUS_1(x, y) (fonction1(x) - fonction2(y))
 
[...]
 
#endif /* _H_MACROS_H_ */

Certains de mes collègues pensent que parce que les macros MACRO_N et MACRO_N_PLUS_1 utilisent des fonctions de toto.h, il faut inclure celui-ci dans macro.h.

Personnellement, je pense l'inverse, histoire que le fichier qui utilise ces macros soit obligé de bien mettre en évidence qu'il inclue toto.h et surtout, si certains projets utilisent les autres macros, ils ne doivent pas être obligés de livrer le fichier toto.h s'ils ne l'utilisent pas.

Qu'en pensez-vous ?

Merci par avance pour vos réponses.

--
Olivier

[bpy1401]

bonjour olivier_u

Moi, je mettrais toto.h dans macro.h.

Je vais justifier ma réponse en disant que l'utilisation de macro.h n'est pas obliger de savoir qu'il faut inclure toto.h. macro.h est donc pour moi auto suffisant. Par contre rien de dit qu'il faut inclure toto.c dans ton link

petite remarque

Nous sommes un groupe de programmateurs à travailler

je préfère programmeur, un programmateur, c'est ce qui pilote ta machine à laver

[diogene]

Certains de mes collègues pensent que parce que les macros MACRO_N et MACRO_N_PLUS_1 utilisent des fonctions de toto.h, il faut inclure celui-ci dans macro.h.

Je ne le ferais pas, parce qu'il n'y a aucune raison.

Par contre, la question que je me poserais c'est de transférer les lignes

Code :

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

1
2
#define MACRO_N(x, y) (fonction1(x) + fonction2(y))
#define MACRO_N_PLUS_1(x, y) (fonction1(x) - fonction2(y))

dans toto.h au lieu de les mettre dans macro.h. C'est a priori leur place logique. Qui utilise les fonctions fonction1 ou fonction2 héritera automatiquement des macro associées et ceux qui ne les utilisent pas n'ont rien à faire avec ces macro.

[olivier_u]

je préfère programmeur, un programmateur, c'est ce qui pilote ta machine à laver

Ça, c'est à cause de la quantité de travail, l'aliénation de notre être nous transforme en machines .

Bon, sinon, sur le sujet, j'ai un pour et un contre... Voilà qui n'aide pas à trancher. Merci quand même pour vos réponses.

Sur le principe, je suis d'accord, je mettrais les deux macros dans toto.h. Malheureusement, nous avons hérité d'une usine à gaz ce qui fait qu'on doit historiquement concentrer les macros dans un seul fichier et de toute façon, en l'espèce, toto.h ne nous appartient pas (c'est une bibliothèque livrée) et nous ne pouvons pas le modifier.

L'argument de bpy1401 est celle de mes détracteurs (ce à quoi j'oppose qu'il s'agit de macros et non de fonctions). Pour ma part, j'affirme que :

1°) comme il s'agit d'une macro, cela revient à remplacer la macro dans le code par le code correspondant (au contraire d'une fonction ou il y a saut vers la fonction) et donc qu'on doit avoir l'include dans le programme appelant la macro,

2°) cela évite aux fonctions utilisant les autres macros d'avoir à appeler des includes qui ne leur serve à rien et sont inutiles lors de la compilation (en particulier quand je livre des tests unitaires).

Bref. .

Merci quand même.

[Jérôme_C]

Le grand dilemme entre atomiser les dépendances, et ainsi maitriser les liaisons entre les différentes parties du produit, et d'un autre côté avoir des déclarations simples pour commencer un projet, deux fichier en-tête pour utiliser une instruction ça va, mais le jeu de piste quand une dépendance en cache une autre, c'est infernal.


Comme le souligne diogene, une macro qui dépend d'une bibliothèque, c'est surprenant. Puis si le projet toto n'est pas nécessaire très souvent, autant avoir les macros que pour le projet. Certes tu ne peux modifier le projet toto, mais tu peux modifier la façon dont tu le déclares dans ton code. Avoir un mon_toto.h, qui contient toto.h et ses macros spécialisés, ça permet de garder les avantages des deux systèmes :
- Si tu as besoin des macros mais pas du projet toto, on appelle que macro.h
- Si tu as besoin que des macros liés au projet toto, on appelle que mon_toto.h
- C'est seulement lorsque tu as besoin des deux, et donc que tu dois inclure dans l'édition des liens le projet toto que tu appelle macro.h et toto.h.


La question est donc de savoir si le projet toto est automatiquement dans l'édition de liens, ou seulement lorsque le besoin s'en est fait sentir.