Ma bibliothèque C a des fonctionnalités optionnelles et utilise automaticis, l'utilisateur peut les activer et éteindre en fournissant des indicateurs à configurer. P>
Si une fonctionnalité est éteinte, cette fonction ne sera pas compilée. P>
Cependant, ma question est que je devrais également supprimer le prototype de fonction des en-têtes publics dans cette affaire? P>
On dirait que ce n'est pas une bonne idée d'avoir des prototypes de fonction pour des fonctions qui ne sont pas compilées, mais il aussi em> me semble pas une bonne idée d'installer différents en-têtes publics en fonction de la configuration de la bibliothèque. (Semblable à la mauvaise pratique d'installer Quelle est la meilleure approche pour les en-têtes publics en matière de fonctionnalités optionnelles? Si un utilisateur tente d'utiliser une fonctionnalité désactivée, l'erreur peut-elle venir au moment de la compilation, ou une heure de liaison? Il doit y avoir une pratique standard pour cette situation. (Je préfère se conformer aux normes de codage GNU s'il existe plusieurs idées, mais je ne connais pas la norme GNU sur cette question.) P> config.h code> dans le répertoire des en-têtes publics.) P>
3 Réponses :
Je pense qu'il y a 2 approches valides de ce problème p>
#Ifdef code> pour supprimer les fonctions qui ne sont pas prises en charge dans certaines configurations li>
- avoir plusieurs fichiers d'en-tête sans
#Ifdef code> chacun d'eux spécifique à une configuration li>
ul>
Cela semble être une très mauvaise pratique de laisser des fonctions qui ne sont pas présentes dans la libère dans le fichier d'en-tête pour une configuration donnée. Il faudra ce qui devrait être une erreur de compilation et la déplacer sur une lieur une. p>
Je n'aime pas la deuxième suggestion, vous pouvez inclure accidentellement les fichiers manuellement.
@Luchiangriggore je suis d'accord que ce n'est pas ma préférence. Je considère que c'est une étape ci-dessus en avoir tout dans un seul fichier, bien que sans #Ifdefs code>
Ne excluez définitivement que l'implication de la mise en œuvre de la compilation, mais toute la fonction.
//feature.h #ifndef EXCLUDE_FEATURE void foo(); #endif //feature.c #include "feature.h" #ifndef EXCLUDE_FEATURE void foo() { } #endif
Droite, merci. J'y ai pensé, mon seul inquiétude est que cela me semble très similaire d'inclure le fichier config.h, par exemple - j'ai eu l'impression que la configuration de la bibliothèque spécifique ne doit pas nécessairement être reflétée dans les en-têtes depuis par ex. Plusieurs versions de la bibliothèque pourraient être installées. C'est vraiment mon seul problème avec cette approche.
J'ai observé l'approche suivante dans certains projets: Générez le fichier d'en-tête d'un modèle un. p>
La génération de fichiers est basée sur les indicateurs de configuration. P>
Cette approche m'a semblé plus propre que d'utiliser des définitions de conditionnels sans fin sur l'en-tête ... Pour moi, cela semble beaucoup plus propre. P>
Inconvénient: il peut s'agir d'un fardeau de support (pour le script). P>
Je pense que c'est une bonne idée de ne pas inclure le prototype si la fonction n'est pas définie, de sorte que l'erreur soit trouvée au moment de la compilation au lieu d'une heure de liaison, mais je ne suis au courant d'aucune pratique standard à ce sujet. J'utiliserais #idif.
@VaughnCato Si le prototype est exclu par une directive de préprocesseur, vous obtiendrez une erreur de compilateur.
@Luchiangriggore Oui, exactement.
@Luchiangriggore Ouais, c'est précisément le point: Si vous faites exclure le préprocesseur excluant la mise en œuvre, désignez également la déclaration afin que les gens obtiennent une erreur de compilateur plutôt que d'une erreur de liaison (liaison éventuellement dynamique aussi!).
Que voulez-vous dire par supprimer? Supprimer effectivement le texte? J'utiliserais #iS pour le supprimer efficacement tout en retirant réellement le texte.
Je ne pense pas qu'il y ait une pratique standard. ZLIB semble installer son en-tête de configuration (comme
zconf.h code>), d'autres bibliothèques fournissent toujours des implémentations de stub qui viennent de renvoyer une erreur "non implémentée".