Ça c'est pour cacher la déclaration des fonctions pour l'utilisateur de la bibliothèque, ça ne change pas la visibilité des symboles dans la bibliothèque ce qui était l'idée originale de l'OP je pense.
Sauf que cacher les symboles internes n'a pas je pense un grand intérêt en particulier dans une bibliothèque libre.
L'important c'est de séparer clairement ce qui fait parti de l'API publique et de ce qu'il ne l'est pas pour éviter des erreurs ou des modifications de l'état interne qui peuvent perturber le reste de la bibliothèque.
Donc avoir un en-tête séparé avec le suffixe _p ou _private fait le job et est assez courant en pratique.
entête privé ou non l'utilisateur de la bibliothèque peut l'appeler et parfois c'est pas ce qu'on souhaite.
Oui enfin dans ce cas si l'appel est fait c'est que la personne cherche explicitement à faire n'importe quoi. Est-ce grave ? L'important c'est d'éviter que cela arrive par accident par quelqu'un qui aurait mal compris l'intention de l'auteur de la bibliothèque.
[^] # Re: #define public
Posté par Renault (site web personnel) . En réponse au journal À table !. Évalué à 5.
Sauf que cacher les symboles internes n'a pas je pense un grand intérêt en particulier dans une bibliothèque libre.
L'important c'est de séparer clairement ce qui fait parti de l'API publique et de ce qu'il ne l'est pas pour éviter des erreurs ou des modifications de l'état interne qui peuvent perturber le reste de la bibliothèque.
Donc avoir un en-tête séparé avec le suffixe
_pou_privatefait le job et est assez courant en pratique.Oui enfin dans ce cas si l'appel est fait c'est que la personne cherche explicitement à faire n'importe quoi. Est-ce grave ? L'important c'est d'éviter que cela arrive par accident par quelqu'un qui aurait mal compris l'intention de l'auteur de la bibliothèque.