En d'autres termes, dans un projet d=92envergure, doit-on minimiser le
nombre d=92appel =E0 des fichiers d=92en-t=EAte dans les fichiers d=92en-t=
=EAtes
(et ce sont les d=E9veloppeurs qui sont responsable de l=92ordre d=92appel
des fichiers d=92en-t=EAte) ? Ou bien, g=E9rer les d=E9pendances entre
fichiers d=92en-t=EAte (et minimiser le nombre d=92appel =E0 des fichiers d=
=92en-
t=EAte dans les fichiers sources) ?
[...](j'ai tout coupé parce qu'il y a des caractères qui ne passent pas)
Ce que j'ai retenu c'est que chaque fichier doit être autonome quant à ses #include. Donc #include-r tout ce qu'il faut et juste ce qu'il faut. C'est donc la proposition "Cas 2" que je choisirais. Attention, si on utilise directement content dans example.c, je suis pour y ajouter un #include "file2.h".
-- Pierre Maurette
Thoma, le 15/09/2009 a écrit :
[...](j'ai tout coupé parce qu'il y a des caractères qui ne passent
pas)
Ce que j'ai retenu c'est que chaque fichier doit être autonome quant à
ses #include. Donc #include-r tout ce qu'il faut et juste ce qu'il
faut. C'est donc la proposition "Cas 2" que je choisirais. Attention,
si on utilise directement content dans example.c, je suis pour y
ajouter un #include "file2.h".
[...](j'ai tout coupé parce qu'il y a des caractères qui ne passent pas)
Ce que j'ai retenu c'est que chaque fichier doit être autonome quant à ses #include. Donc #include-r tout ce qu'il faut et juste ce qu'il faut. C'est donc la proposition "Cas 2" que je choisirais. Attention, si on utilise directement content dans example.c, je suis pour y ajouter un #include "file2.h".
-- Pierre Maurette
Wykaaa
Thoma a écrit :
Bonjour,
[couic]
En d'autres termes, dans un projet d’envergure, doit-on minimiser le nombre d’appel à des fichiers d’en-tête dans les fichiers d’en-têtes (et ce sont les développeurs qui sont responsable de l’ordre d’appel des fichiers d’en-tête) ? Ou bien, gérer les dépendances entre fichiers d’en-tête (et minimiser le nombre d’appel à des fichiers d’en- tête dans les fichiers sources) ?
D'avance merci
Thoma
Si l'on a une approche objet, les .h représentent les classes (en C : un objet avec sa structure + les prototypes des fonctions qui concernent cette structure). Les dépendances entre fichiers d'en-tête correspondent donc aux dépendances entre objets telles qu'identifiées lors de la conception globale.
Je ne vois d'ailleurs pas de prototype de fonctions dans tes fichiers d'en-tête. Où sont-ils ?
Thoma a écrit :
Bonjour,
[couic]
En d'autres termes, dans un projet d’envergure, doit-on minimiser le
nombre d’appel à des fichiers d’en-tête dans les fichiers d’en-têtes
(et ce sont les développeurs qui sont responsable de l’ordre d’appel
des fichiers d’en-tête) ? Ou bien, gérer les dépendances entre
fichiers d’en-tête (et minimiser le nombre d’appel à des fichiers d’en-
tête dans les fichiers sources) ?
D'avance merci
Thoma
Si l'on a une approche objet, les .h représentent les classes (en C : un
objet avec sa structure + les prototypes des fonctions qui concernent
cette structure).
Les dépendances entre fichiers d'en-tête correspondent donc aux
dépendances entre objets telles qu'identifiées lors de la conception
globale.
Je ne vois d'ailleurs pas de prototype de fonctions dans tes fichiers
d'en-tête. Où sont-ils ?
En d'autres termes, dans un projet d’envergure, doit-on minimiser le nombre d’appel à des fichiers d’en-tête dans les fichiers d’en-têtes (et ce sont les développeurs qui sont responsable de l’ordre d’appel des fichiers d’en-tête) ? Ou bien, gérer les dépendances entre fichiers d’en-tête (et minimiser le nombre d’appel à des fichiers d’en- tête dans les fichiers sources) ?
D'avance merci
Thoma
Si l'on a une approche objet, les .h représentent les classes (en C : un objet avec sa structure + les prototypes des fonctions qui concernent cette structure). Les dépendances entre fichiers d'en-tête correspondent donc aux dépendances entre objets telles qu'identifiées lors de la conception globale.
Je ne vois d'ailleurs pas de prototype de fonctions dans tes fichiers d'en-tête. Où sont-ils ?
-ed-
On 15 sep, 14:54, Thoma wrote:
Cas 2: ----------------------------------- file1.h ------------------------------------ #ifndef __FILE1_H__ #define __FILE1_H__
En d'autres termes, dans un projet denvergure, doit-on minimiser le nombre dappel à des fichiers den-tête dans les fichiers den- têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à utiliser.
(et ce sont les développeurs qui sont responsable de lordre dappe l des fichiers den-tête) ? Ou bien, gérer les dépendances entre fichiers den-tête (et minimiser le nombre dappel à des fichiers den- tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance ( 'container' dépend de 'content' ) . Celle ci- est réglée automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C attribue les identificateurs commençant par _ à l'implémentation. Je suggère :
En d'autres termes, dans un projet denvergure, doit-on minimiser le
nombre dappel à des fichiers den-tête dans les fichiers den- têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à
utiliser.
(et ce sont les développeurs qui sont responsable de lordre dappe l
des fichiers den-tête) ? Ou bien, gérer les dépendances entre
fichiers den-tête (et minimiser le nombre dappel à des fichiers den-
tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance
( 'container' dépend de 'content' ) . Celle ci- est réglée
automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul
fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C
attribue les identificateurs commençant par _ à l'implémentation. Je
suggère :
En d'autres termes, dans un projet denvergure, doit-on minimiser le nombre dappel à des fichiers den-tête dans les fichiers den- têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à utiliser.
(et ce sont les développeurs qui sont responsable de lordre dappe l des fichiers den-tête) ? Ou bien, gérer les dépendances entre fichiers den-tête (et minimiser le nombre dappel à des fichiers den- tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance ( 'container' dépend de 'content' ) . Celle ci- est réglée automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C attribue les identificateurs commençant par _ à l'implémentation. Je suggère :
> En d'autres termes, dans un projet denvergure, doit-on minimiser le > nombre dappel à des fichiers den-tête dans les fichiers de n-têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à utiliser.
> (et ce sont les développeurs qui sont responsable de lordre dap pel > des fichiers den-tête) ? Ou bien, gérer les dépendances entre > fichiers den-tête (et minimiser le nombre dappel à des fichie rs den- > tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance ( 'container' dépend de 'content' ) . Celle ci- est réglée automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C attribue les identificateurs commençant par _ à l'implémentation. J e suggère :
#ifndef H_FILE1 #define H_FILE1
http://www.bien-programmer.fr/codage.php#organiser_sourcehttp://www.bien- programmer.fr/codage.php#organiser- Masquer le texte des messages précé dents -
- Afficher le texte des messages précédents -
Bonjour,
Avant tout, merci à vous d'avoir passer du temps sur cette question.
-> Pierre MAURETTE Je suis d'accord avec vous concernant l'inclusion de "file2.h" si l'on utilise 'content'.
-> Wykaaa L'exemple n'est pas complet et ne soulève que la problématique des dépendances entre fichiers d'en-tête d'où l'absence des prototypes de fonction.
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
On 15 sep, 20:01, -ed- <emmanuel.delah...@gmail.com> wrote:
On 15 sep, 14:54, Thoma <thoma.h...@gmail.com> wrote:
> En d'autres termes, dans un projet denvergure, doit-on minimiser le
> nombre dappel à des fichiers den-tête dans les fichiers de n-têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à
utiliser.
> (et ce sont les développeurs qui sont responsable de lordre dap pel
> des fichiers den-tête) ? Ou bien, gérer les dépendances entre
> fichiers den-tête (et minimiser le nombre dappel à des fichie rs den-
> tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance
( 'container' dépend de 'content' ) . Celle ci- est réglée
automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul
fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C
attribue les identificateurs commençant par _ à l'implémentation. J e
suggère :
#ifndef H_FILE1
#define H_FILE1
http://www.bien-programmer.fr/codage.php#organiser_sourcehttp://www.bien- programmer.fr/codage.php#organiser- Masquer le texte des messages précé dents -
- Afficher le texte des messages précédents -
Bonjour,
Avant tout, merci à vous d'avoir passer du temps sur cette question.
-> Pierre MAURETTE
Je suis d'accord avec vous concernant l'inclusion de "file2.h" si l'on
utilise 'content'.
-> Wykaaa
L'exemple n'est pas complet et ne soulève que la problématique des
dépendances entre fichiers d'en-tête d'où l'absence des prototypes de
fonction.
-> -ed-
Effectivement, j'ai encore de vieilles habitudes à gommer concernant
le choix des identificateurs.
J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
> En d'autres termes, dans un projet denvergure, doit-on minimiser le > nombre dappel à des fichiers den-tête dans les fichiers de n-têtes
on doit faire ce qu'il faut pour que le code soit simple à coder et à utiliser.
> (et ce sont les développeurs qui sont responsable de lordre dap pel > des fichiers den-tête) ? Ou bien, gérer les dépendances entre > fichiers den-tête (et minimiser le nombre dappel à des fichie rs den- > tête dans les fichiers sources) ?
Le deuxième cas est à préférer, car il y a une dépendance ( 'container' dépend de 'content' ) . Celle ci- est réglée automatiquement par le deuxième cas. L'utilisateur n'a qu'un seul fichier d'entête à gérer.
Attention, si ce code est applicatif, il est incorrect. Le langage C attribue les identificateurs commençant par _ à l'implémentation. J e suggère :
#ifndef H_FILE1 #define H_FILE1
http://www.bien-programmer.fr/codage.php#organiser_sourcehttp://www.bien- programmer.fr/codage.php#organiser- Masquer le texte des messages précé dents -
- Afficher le texte des messages précédents -
Bonjour,
Avant tout, merci à vous d'avoir passer du temps sur cette question.
-> Pierre MAURETTE Je suis d'accord avec vous concernant l'inclusion de "file2.h" si l'on utilise 'content'.
-> Wykaaa L'exemple n'est pas complet et ne soulève que la problématique des dépendances entre fichiers d'en-tête d'où l'absence des prototypes de fonction.
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Wykaaa
Thoma a écrit :
[couic]
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
Thoma a écrit :
[couic]
-> -ed-
Effectivement, j'ai encore de vieilles habitudes à gommer concernant
le choix des identificateurs.
J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les
identificateurs commençant pas _ mais la "coutume".
Dans Unix, la "coutume" veut que les variables système commencent par _
Une application ne devrait donc jamais utiliser de variables dont le nom
commence par ce caractère.
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
espie
In article <4ab09ace$0$17738$, Wykaaa wrote:
Thoma a écrit :
[couic]
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a: - des compilateurs - des systemes - une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont *reserves pour l'implementation* (je laisse de cote les details, l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette specification, tu risques les collisions avec les details internes de l'implementation, que ce soit ton compilo, ou le reste du systeme: si ton programme continue a marcher, c'est par accident, car tu n'as plus aucune garantie que tu n'entres pas en conflit, de maniere plus ou moins sournoise, avec des details internes de ton compilateur, ou de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe: a chaque fois que tu changes de compilateur, tu t'exposes a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes les joies que ca occasionne...
In article <4ab09ace$0$17738$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Thoma a écrit :
[couic]
-> -ed-
Effectivement, j'ai encore de vieilles habitudes à gommer concernant
le choix des identificateurs.
J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les
identificateurs commençant pas _ mais la "coutume".
Dans Unix, la "coutume" veut que les variables système commencent par _
Une application ne devrait donc jamais utiliser de variables dont le nom
commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le
contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a:
- des compilateurs
- des systemes
- une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont
*reserves pour l'implementation* (je laisse de cote les details,
l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette
specification, tu risques les collisions avec les details internes de
l'implementation, que ce soit ton compilo, ou le reste du systeme:
si ton programme continue a marcher, c'est par accident, car tu n'as plus
aucune garantie que tu n'entres pas en conflit, de maniere
plus ou moins sournoise, avec des details internes de ton compilateur, ou
de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe:
a chaque fois que tu changes de compilateur, tu t'exposes
a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes
les joies que ca occasionne...
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a: - des compilateurs - des systemes - une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont *reserves pour l'implementation* (je laisse de cote les details, l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette specification, tu risques les collisions avec les details internes de l'implementation, que ce soit ton compilo, ou le reste du systeme: si ton programme continue a marcher, c'est par accident, car tu n'as plus aucune garantie que tu n'entres pas en conflit, de maniere plus ou moins sournoise, avec des details internes de ton compilateur, ou de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe: a chaque fois que tu changes de compilateur, tu t'exposes a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes les joies que ca occasionne...
-ed-
On 16 sep, 09:59, Wykaaa wrote:
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume".
Bah non. C'est bien défini dans le langage C. L'usage des identificateurs commençant par _ est réservé à l"implémentation.
Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
On 16 sep, 09:59, Wykaaa <wyk...@yahoo.fr> wrote:
Ce n'est pas le langage C qui impose quoi que ce soit concernant les
identificateurs commençant pas _ mais la "coutume".
Bah non. C'est bien défini dans le langage C. L'usage des
identificateurs commençant par _ est réservé à l"implémentation.
Dans Unix, la "coutume" veut que les variables système commencent par _
Une application ne devrait donc jamais utiliser de variables dont le nom
commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
Wykaaa
Marc Espie a écrit :
In article <4ab09ace$0$17738$, Wykaaa wrote:
Thoma a écrit :
[couic]
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a: - des compilateurs - des systemes - une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont *reserves pour l'implementation* (je laisse de cote les details, l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette specification, tu risques les collisions avec les details internes de l'implementation, que ce soit ton compilo, ou le reste du systeme: si ton programme continue a marcher, c'est par accident, car tu n'as plus aucune garantie que tu n'entres pas en conflit, de maniere plus ou moins sournoise, avec des details internes de ton compilateur, ou de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe: a chaque fois que tu changes de compilateur, tu t'exposes a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes les joies que ca occasionne...
OK. Je suis d'accord que j'ai fait un "raccourci". D'un autre côté "réservé à l'implémentation" n'est pas complètement clair non plus. Ceci dit, on sent bien qu'il faut se méfier...
Marc Espie a écrit :
In article <4ab09ace$0$17738$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Thoma a écrit :
[couic]
-> -ed-
Effectivement, j'ai encore de vieilles habitudes à gommer concernant
le choix des identificateurs.
J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les
identificateurs commençant pas _ mais la "coutume".
Dans Unix, la "coutume" veut que les variables système commencent par _
Une application ne devrait donc jamais utiliser de variables dont le nom
commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le
contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a:
- des compilateurs
- des systemes
- une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont
*reserves pour l'implementation* (je laisse de cote les details,
l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette
specification, tu risques les collisions avec les details internes de
l'implementation, que ce soit ton compilo, ou le reste du systeme:
si ton programme continue a marcher, c'est par accident, car tu n'as plus
aucune garantie que tu n'entres pas en conflit, de maniere
plus ou moins sournoise, avec des details internes de ton compilateur, ou
de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe:
a chaque fois que tu changes de compilateur, tu t'exposes
a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes
les joies que ca occasionne...
OK. Je suis d'accord que j'ai fait un "raccourci". D'un autre côté
"réservé à l'implémentation" n'est pas complètement clair non plus. Ceci
dit, on sent bien qu'il faut se méfier...
-> -ed- Effectivement, j'ai encore de vieilles habitudes à gommer concernant le choix des identificateurs. J'avais déjà trainer sur le lien que vous proposez.
Si d'autres personnes pouvez infirmer ou confirmer ces avis?
D'avance merci
Thoma
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume". Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
La formulation est hasardeuse, on pourrait presque lui faire dire le contraire de ce que tu as dis.
C'est quoi "le langage C" ? Il y a: - des compilateurs - des systemes - une norme.
Tu melanges sauvagement les trois...
La norme stipule clairement que les identifiants commencant par _ sont *reserves pour l'implementation* (je laisse de cote les details, l'idee est la).
En terme de "coutumes", ca veut juste dire que, si tu outrepasses cette specification, tu risques les collisions avec les details internes de l'implementation, que ce soit ton compilo, ou le reste du systeme: si ton programme continue a marcher, c'est par accident, car tu n'as plus aucune garantie que tu n'entres pas en conflit, de maniere plus ou moins sournoise, avec des details internes de ton compilateur, ou de ton systeme.
Meme pour le systeme, il faut quand meme faire gaffe: a chaque fois que tu changes de compilateur, tu t'exposes a des soucis supplementaires, la separation n'est pas tres nette !
Me suis deja tape quelques migrations de versions de gcc, avec toutes les joies que ca occasionne...
OK. Je suis d'accord que j'ai fait un "raccourci". D'un autre côté "réservé à l'implémentation" n'est pas complètement clair non plus. Ceci dit, on sent bien qu'il faut se méfier...
Wykaaa
-ed- a écrit :
On 16 sep, 09:59, Wykaaa wrote:
Ce n'est pas le langage C qui impose quoi que ce soit concernant les identificateurs commençant pas _ mais la "coutume".
Bah non. C'est bien défini dans le langage C. L'usage des identificateurs commençant par _ est réservé à l"implémentation.
Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
Alors voici ce que dit le document que tu cites en référence (qui n'est qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page 167 :
163) Because external identifiers and some macro names beginning with an underscore are reserved, implementations may provide special semantics for such names. For example, the identifier _BUILTIN_abs could be used to indicate generation of in-line code for the abs function.
Il faut savoir lire : il y a une virgule entre reserved et implementations. Et la fin de la phrase dit (c'est moi qui souligne): implementations _may_ provide special semantics for such names
Dans ce même document, il est dit (§6.4.2.1, page 51) : An identifier is a sequence of nondigit characters (including the underscore _, the lowercase and uppercase Latin letters, and other characters) and digits,
Donc ce que dit la norme entérine le fait que c'était une coutume de commencer les identificateurs "système" par un _
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un compilateur ne fera pas de vérification) mais c'est à tes risques et périls...
-ed- a écrit :
On 16 sep, 09:59, Wykaaa <wyk...@yahoo.fr> wrote:
Ce n'est pas le langage C qui impose quoi que ce soit concernant les
identificateurs commençant pas _ mais la "coutume".
Bah non. C'est bien défini dans le langage C. L'usage des
identificateurs commençant par _ est réservé à l"implémentation.
Dans Unix, la "coutume" veut que les variables système commencent par _
Une application ne devrait donc jamais utiliser de variables dont le nom
commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
Alors voici ce que dit le document que tu cites en référence (qui n'est
qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page
167 :
163) Because external identifiers and some macro names beginning with an
underscore are reserved, implementations may provide special semantics
for such names. For example, the identifier _BUILTIN_abs could be used
to indicate generation of in-line code for the abs function.
Il faut savoir lire : il y a une virgule entre reserved et implementations.
Et la fin de la phrase dit (c'est moi qui souligne):
implementations _may_ provide special semantics for such names
Dans ce même document, il est dit (§6.4.2.1, page 51) :
An identifier is a sequence of nondigit characters (including the
underscore _, the lowercase and uppercase Latin letters, and other
characters) and digits,
Donc ce que dit la norme entérine le fait que c'était une coutume de
commencer les identificateurs "système" par un _
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un
compilateur ne fera pas de vérification) mais c'est à tes risques et
périls...
Dans Unix, la "coutume" veut que les variables système commencent par _ Une application ne devrait donc jamais utiliser de variables dont le nom commence par ce caractère.
Y' pas que dans Unix. C'est imposé par le langage...
Alors voici ce que dit le document que tu cites en référence (qui n'est qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page 167 :
163) Because external identifiers and some macro names beginning with an underscore are reserved, implementations may provide special semantics for such names. For example, the identifier _BUILTIN_abs could be used to indicate generation of in-line code for the abs function.
Il faut savoir lire : il y a une virgule entre reserved et implementations. Et la fin de la phrase dit (c'est moi qui souligne): implementations _may_ provide special semantics for such names
Dans ce même document, il est dit (§6.4.2.1, page 51) : An identifier is a sequence of nondigit characters (including the underscore _, the lowercase and uppercase Latin letters, and other characters) and digits,
Donc ce que dit la norme entérine le fait que c'était une coutume de commencer les identificateurs "système" par un _
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un compilateur ne fera pas de vérification) mais c'est à tes risques et périls...
Richard Delorme
Le 16/09/2009 12:49, Wykaaa a écrit :
Alors voici ce que dit le document que tu cites en référence (qui n'est qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page 167 :
Le bon paragraphe est le 7.1.3 : [...] — All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. — All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un compilateur ne fera pas de vérification) mais c'est à tes risques et périls...
Si : [...]If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
-- Richard
Le 16/09/2009 12:49, Wykaaa a écrit :
Alors voici ce que dit le document que tu cites en référence (qui n'est
qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page
167 :
Le bon paragraphe est le 7.1.3 :
[...]
— All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for
use as identifiers with file scope in both the ordinary and tag name spaces.
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un
compilateur ne fera pas de vérification) mais c'est à tes risques et
périls...
Si :
[...]If the program declares or defines an identifier in a
context in which it is reserved (other than as allowed by 7.1.4), or
defines a reserved identifier as a macro name, the behavior is undefined.
Alors voici ce que dit le document que tu cites en référence (qui n'est qu'un draft de la norme) et c'est une note de bas de page (§ 7.1.4, page 167 :
Le bon paragraphe est le 7.1.3 : [...] — All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. — All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Elle n'impose rien du tout (puisque c'est autorisé dans le langage, un compilateur ne fera pas de vérification) mais c'est à tes risques et périls...
Si : [...]If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.