IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

mot clé extern


Sujet :

C

  1. #1
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 299
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 299
    Par défaut mot clé extern
    bonjour, sur la page suivante section 7.2.1 Fichier en-tête d'un fichier source il est marqué : "Par ailleurs, il faut faire précéder la déclaration de la fonction du mot-clef extern, qui signifie que cette fonction est définie dans un autre fichier"

    et il est mis en exemple :

    /**********************************************************************/
    /*** fichier: produit.h ***/
    /*** en-tete de produit.c ***/
    /**********************************************************************/

    extern int produit(int, int);

    pour ma part, dans mon .h, je ne mets jamais le mot clé extern. Est-ce que cela change bcp de chose de ne pas le mettre ?

    Merci.

  2. #2
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    ce n'est pas obligatoire, mais c'est la meilleure pratique

  3. #3
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Par défaut
    Citation Envoyé par salseropom
    Est-ce que cela change bcp de chose de ne pas le mettre ?
    Bin non, le prototype de la fonction étant dans un header, elle est automatiquement extern, chose tout à fait logique vu qu'il suffit d'inclure le header dans un fichier source.
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    1 299
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 299
    Par défaut
    OK, merci de vos précisions.

    Merci aussi pour les cours de programmation langage C et la FAQ Langage C

  5. #5
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    j'ai tapé trop tot sur envoyer...

    Non ce n'est pas obligatoire, mais c'est recommandé pour plusieurs raisons.

    La première est la lisibilité et la séparation de ce qui est privé et publique.

    Toute fonction à usage exclusif d'un module devrait être déclarée "static".

    Toute fonction non déclarée comme "static" est utilisable à l'extérieur, qu'elle soit ou non dans un ".h", pour peu que l'utilisateur sache comment cette fonction s'appelle....

    Donc, au vu des 2 phrases ci-dessus, un ".h" ne devrait donc contenir que des fonctions à usage public.

    Le mot-clé extern n'est pas obligatoire, mais préféré car :

    - un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
    Si par contre la fonction était déclarée extern, le compilateur se plaindra...

    - Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...

  6. #6
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    Citation Envoyé par salseropom
    extern int produit(int, int);

    pour ma part, dans mon .h, je ne mets jamais le mot clé extern. Est-ce que cela change bcp de chose de ne pas le mettre ?
    Pour les fonctions, le mot clé extern devant un prototype a une valeur purement documentaire. On a le droit de l'omettre

  7. #7
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    Citation Envoyé par souviron34
    jLa première est la lisibilité et la séparation de ce qui est privé et publique.
    Huh ! Les interfaces publiques sont dans le .h. Ce qui est privé (static) est dans le .c et est rarement séparé de son implémentation... Je ne vois pas ce qu'extern apporte là-dedans. La séparation est 'géographique'.

    http://emmanuel-delahaye.developpez....ganiser_source
    http://emmanuel-delahaye.developpez.....htm#organiser
    Toute fonction à usage exclusif d'un module devrait être déclarée "static".
    OK.
    Toute fonction non déclarée comme "static" est utilisable à l'extérieur, qu'elle soit ou non dans un ".h", pour peu que l'utilisateur sache comment cette fonction s'appelle....
    Il est d'usage (Bonne Manière) qu'elle ait un prototype séparé et qui soit placé dans un .h visible de l'implémentation (une option de gcc permet de faire un warning en cas de manquement).
    Donc, au vu des 2 phrases ci-dessus, un ".h" ne devrait donc contenir que des fonctions à usage public.
    Tu parles de prototypes, bien sûr...

    [C99] Le cas des fonctions inline est un peu étrange, car il existe des 'static inline'...
    Le mot-clé extern n'est pas obligatoire, mais préféré car :

    - un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
    Si par contre la fonction était déclarée extern, le compilateur se plaindra...
    Mmm... possible... portable ?
    - Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...
    Moui, pas sur que ce soit une exigence du langage, mais plutôt une QoI (Quality of Implementation)

  8. #8
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Emmanuel Delahaye
    Il est d'usage (Bonne Manière) qu'elle ait un prototype séparé et qui soit placé dans un .h visible de l'implémentation (une option de gcc permet de faire un warning en cas de manquement).

    Tu parles de prototypes, bien sûr...
    OUI mais c'était justement le sens de sa question d'origine...
    (visiblement il avait envie de se passer des extern...)
    Et TOUTE fonction même non déclarée dans le '.h", si elle n'est pas déclarée statique, peut être appelée par tout module externe, pour peu qu'on se lie avec la bonne bibliothèque..

    [C99] Le cas des fonctions inline est un peu étrange, car il existe des 'static inline'...
    Il me semble que ça existait aussi avant, non ?


    Le mot-clé extern n'est pas obligatoire, mais préféré car :

    - un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
    Si par contre la fonction était déclarée extern, le compilateur se plaindra...
    Mmm... possible... portable ?

    - Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...
    Moui, pas sur que ce soit une exigence du langage, mais plutôt une QoI (Quality of Implementation)
    Ce n'est pas une exigence du tout (quoique... voir plus bas.. mais je ne connais pas les specs des compilos), mais c'est constant dans les implémentations, ne serait-ce que pour répondre aux gens qui mettent des protoypes vides en tête de leurs modules (une reminiscence de Pascal, sans doute )

    Quand tu mets un proto vide en tête, quand le compilo rencontre la vraie défintion, il remplace. (suivant l'ordre de compil ou de liens)

    Et donc c'est hautement dangereux, si la fonction porte le même nom qu'une qui est dans un ".h" et n'est pas déclarée extern, car elle est alors remplacée... et réciproquement...

    Exemple :

    faire appel à sqrt sans avoir inclus "math.h" ne provoque pas de scandale (en tout cas pas que j'ai vu), mais sort 0... D'ailleurs toutes les fonctions de maths se comprtent de la même manière (log par exemple)...

  9. #9
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    Citation Envoyé par souviron34
    faire appel à sqrt sans avoir inclus "math.h" ne provoque pas de scandale
    What ? Appeler une fonction sans prototype invoque un comportement indéfini. Si ton compilateur est bien réglé, il le signale. C'est tout le sens de l'invention du C89/90 : les prototypes.

    http://emmanuel-delahaye.developpez....tm#cfg_compilo

    (Si tu as des réglages pour d'autres compilateurs, je me ferais un plaisir de les ajouter).

  10. #10
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Citation Envoyé par souviron34
    >>[C99] Le cas des fonctions inline est un peu étrange, car il existe des 'static inline'...

    Il me semble que ça existait aussi avant, non ?
    Pas en tant que C standard : Avant C99, c'était disponible en C++ et en tant qu'extension GNU.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  11. #11
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    mon exemple n'était pas forcément le bon pour démontrer ce que je voulais dire

    Mais il me semble me souvenir (je n'ai plus les machines sous la main) que sous des HP (type 9000), des Silicon (IRIX), des Sun Sparc, et Linux (redhat), si tu fais un petit module appelant par exemple sqrt, mais..je me souviens plus la situation, si c'est d'abord inclure math puis inclure autre chose, ou pas l'inclure du tout, avec les flags "normaux de compil, ça te jette pas, mais toutes les fonctions de maths renvoient zéro (peut-être définies quelque part dans la stdlib ou qque chose comme ça...)...

    Mais bon, je m'accrocherais pas à ça

    Mon point important était sur le reste : si tu ne définis pas comme extern les fonctions dans le ".h", tu risques (enfin quelqu'un) peut écraser soit sa fonction soit celle du module auquel il se réfère....

  12. #12
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Par défaut
    Citation Envoyé par souviron34
    Mon point important était sur le reste : si tu ne définis pas comme extern les fonctions dans le ".h", tu risques (enfin quelqu'un) peut écraser soit sa fonction soit celle du module auquel il se réfère....
    Un compilateur correct et correctement regle te le signalera.

    En outre ce n'est pas une partique courante (je n'ai quasiment jamais vu d'extern dans les header) et l'absence de extern dans les .h n'est certainement une source d'erreur courante (je n'ai jamais vu d'erreur a l'execution a cause de ca).

  13. #13
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par gl
    Un compilateur correct et correctement regle te le signalera.

    En outre ce n'est pas une partique courante (je n'ai quasiment jamais vu d'extern dans les header) et l'absence de extern dans les .h n'est certainement une source d'erreur courante (je n'ai jamais vu d'erreur a l'execution a cause de ca).
    ben non du tout....

    Juste voir les posts plus haut....

    1) c'est au contraire la "régle de bonne conduite courante" d'avoir les fonctions extern dans les headers
    (voir les citations plus haut , plus, si tu veux une preuve supplémentaire, tous les "h" du W3C qu'on peut trouver ici http://www.w3.org/Library/src/WWWStream.html....)

    2) Et un compilateur ne te le signalera pas pour la raison sus-mentionnée dans les post précdents (pré-déclarations de prototype)....


  14. #14
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Par défaut
    Citation Envoyé par souviron34
    1) c'est au contraire la "régle de bonne conduite courante" d'avoir les fonctions extern dans les headers
    Ah peut etre. Toutefois depuis que je travaille, je ne l'ai vu que tres rarement dans le code et jamais dans les regles de programmations.


    Citation Envoyé par souviron34
    plus, si tu veux une preuve supplémentaire, tous les "h" du W3C qu'on peut trouver ici http://www.w3.org/Library/src/WWWStream.html....)
    C'est un choix du W3C de mettre extern dans tous les .h. Je respecte ce choix mais ca n'engage qu'eux.

    Citation Envoyé par souviron34
    2) Et un compilateur ne te le signalera pas pour la raison sus-mentionnée dans les post précdents (pré-déclarations de prototype)....
    Ah bon, je ne sais pas ce que tu utilises et avec quelles options, mais dans mon code si j'ai un prototype (avec un sans extern) different de la definition d'une fonction (ou de l'utilisation d'une fonction), le compilateur me le signale.

    Entendons-nous bien, je ne critique pas du tout l'utilisation d'extern, ni le choix de certains de l'imposer dans leurs regles de codage.
    Mais ce n'est pas indispensable (jamais vu de probleme du a son absence) ni tres frequent (tout au moins pas dans le milieu dans lequel je travaille).

    Bien entendu, dans le cas de variables globales, c'est tout a fait differents, extern est dans ce cas indispensable.

  15. #15
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par gl
    Ah peut etre. Toutefois depuis que je travaille, je ne l'ai vu que tres rarement dans le code et jamais dans les regles de programmations.
    Voir
    http://c.ftp-developpez.com/downloads/c/regle.pdf

    ou

    http://www.flounder.com/ultimateheaderfile.htm

    ou

    http://www.opengl.org/documentation/...3/node110.html


    Citation Envoyé par gl
    C'est un choix du W3C de mettre extern dans tous les .h. Je respecte ce choix mais ca n'engage qu'eux.
    Non Ils ont suivi les règles de bonne manière en usage depuis des lustres...

    Une preuve supplémentaire, voici un extrait d'un include de XFree86.. Regardes en particulier les dates, et la fin...

    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
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
     
    /* $Xorg: Xutil.h,v 1.7 2000/08/17 19:45:08 cpqbld Exp $ */
     
    /***********************************************************
     
    Copyright 1987, 1998  The Open Group
     
    All Rights Reserved.
     
    The above copyright notice and this permission notice shall be included in
    all copies or substantial portions of the Software.
     
    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
    OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
    AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
     
    Except as contained in this notice, the name of The Open Group shall not be
    used in advertising or otherwise to promote the sale, use or other dealings
    in this Software without prior written authorization from The Open Group.
     
     
    Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts.
     
                            All Rights Reserved
     
    Permission to use, copy, modify, and distribute this software and its 
    documentation for any purpose and without fee is hereby granted, 
    provided that the above copyright notice appear in all copies and that
    both that copyright notice and this permission notice appear in 
    supporting documentation, and that the name of Digital not be
    used in advertising or publicity pertaining to distribution of the
    software without specific, written prior permission.  
     
    DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
    ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
    DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
    ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
    WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
    SOFTWARE.
     
    ******************************************************************/
    /* $XFree86: xc/lib/X11/Xutil.h,v 3.3 2001/01/17 19:41:50 dawes Exp $ */
     
    #ifndef _XUTIL_H_
    #define _XUTIL_H_
     
    /* You must include <X11/Xlib.h> before including this file */
    #include <X11/Xlib.h>
     
    /* 
     * Bitmask returned by XParseGeometry().  Each bit tells if the corresponding
     * value (x, y, width, height) was found in the parsed string.
     */
    #define NoValue		0x0000
    #define XValue  	0x0001
    #define YValue		0x0002
    #define WidthValue  	0x0004
    #define HeightValue  	0x0008
    #define AllValues 	0x000F
    #define XNegative 	0x0010
    #define YNegative 	0x0020
     
    /*
     * new version containing base_width, base_height, and win_gravity fields;
     * used with WM_NORMAL_HINTS.
     */
    typedef struct {
        	long flags;	/* marks which fields in this structure are defined */
    	int x, y;		/* obsolete for new window mgrs, but clients */
    	int width, height;	/* should set so old wm's don't mess up */
    	int min_width, min_height;
    	int max_width, max_height;
        	int width_inc, height_inc;
    	struct {
    		int x;	/* numerator */
    		int y;	/* denominator */
    	} min_aspect, max_aspect;
    	int base_width, base_height;		/* added by ICCCM version 1 */
    	int win_gravity;			/* added by ICCCM version 1 */
    } XSizeHints;
     
    ..........
    ...........
    ..........
     
     
    _XFUNCPROTOBEGIN
     
    /* The following declarations are alphabetized. */
     
    extern XClassHint *XAllocClassHint (
    #if NeedFunctionPrototypes
        void
    #endif
    );
     
    extern XIconSize *XAllocIconSize (
    #if NeedFunctionPrototypes
        void
    #endif
    );
     
    extern XSizeHints *XAllocSizeHints (
    #if NeedFunctionPrototypes
        void
    #endif
    );
     
    extern XStandardColormap *XAllocStandardColormap (
    #if NeedFunctionPrototypes
        void
    #endif
    );
     
    ......
    ......
     
     
    extern int XXorRegion(
    #if NeedFunctionPrototypes
        Region		/* sra */,
        Region		/* srb */,
        Region		/* dr_return */
    #endif
    );
     
    _XFUNCPROTOEND
     
    #endif /* _XUTIL_H_ */


    Citation Envoyé par gl
    Ah bon, je ne sais pas ce que tu utilises et avec quelles options, mais dans mon code si j'ai un prototype (avec un sans extern) different de la definition d'une fonction (ou de l'utilisation d'une fonction), le compilateur me le signale.Mais ce n'est pas indispensable
    Tout est dans le différent ... Si tu as la même définition, mais un contenu différent, ça ne te jetteras pas, mais ça prendra la dernière linkée.... Donc tout dépendra de l'ordre dans lequel c'est linké, et l'un ou l'autre de toutes façons ne marchera pas correctement...


    Citation Envoyé par gl
    (jamais vu de probleme du a son absence) ni tres frequent (tout au moins pas dans le milieu dans lequel je travaille).
    Ben c'est au contraire le plus fréquent.... Pas indispensable, mais recommandé...


    Citation Envoyé par gl
    Bien entendu, dans le cas de variables globales, c'est tout a fait differents, extern est dans ce cas indispensable.
    Rhaaa Enfer et damnation !!!

    C'est le contraire !! SURTOUT PAS de variables dans les .h
    (voir les arguments ci-dessus de possibles multiplicité des déclarations, plus les usages de bonnes pratiques que tu trouveras ici.... )

    Si des variables doivent être disponibles à l'extérieur , il faut les passer en paramètres. Si elles sont globales à ton module, mais non accessibles à l'extérieur, elles doivent être statiques....

    Un .h sert à l'extérieur du module, à montrer ce qui est publique...

    Normalement un .h ne devrait contenir (en gros) que :

    des définitions de constantes
    des définitions de structures
    des définitions de fonctions publiques (extern )



  16. #16
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    Citation Envoyé par souviron34
    C'est le contraire !! SURTOUT PAS de variables dans les .h
    (voir les arguments ci-dessus de possibles multiplicité des déclarations, plus les usages de bonnes pratiques que tu trouveras ici.... )
    On est tous d'accord que les variables persistantes modifiables de portée globale sont à éviter. Mais le cas des globales à lecture seule (const) peut simplifier le codage et dans ce cas, une déclaration (extern) suffit. Il n'y a pas de mal à ça.
    Si des variables doivent être disponibles à l'extérieur , il faut les passer en paramètres. Si elles sont globales à ton module, mais non accessibles à l'extérieur, elles doivent être statiques....
    Le problème des variable persistantes statiques n'est pas qu'un problème de portée... C'est aussi et surtout un problème d'instanciation. Pour des données de très haut niveau dont on sait pertinemment qu'elles sont uniques, OK.

    Mais très souvent, on a besoin d'instanciation et dans ce cas, seule l'allocation dynamique est suffisamment souple. Mais j'admets la méthode intermédiaire de l'allocateur manuel (tableau de taille fixe...) si le nombre d'instanciations possibles est limité (par le matériel, notamment).

    Mais bon, le coude souple, c'est bien... Et c'est surtout directement réutilisable sans recompilation (bibliothèques)...
    Un .h sert à l'extérieur du module, à montrer ce qui est publique...

    Normalement un .h ne devrait contenir (en gros) que :

    des définitions de constantes
    des définitions de structures
    des définitions de fonctions publiques (extern )
    On est d'accord...

    http://emmanuel-delahaye.developpez....ganiser_source

    Voici par exemple, une liste de séparateurs utilisés pour structurer des fichiers d'en-tête :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    /* macros ============================================================== */
    /* constants =========================================================== */
    /* types =============================================================== */
    /* structures ========================================================== */
    /* internal public functions =========================================== */
    /* entry points ======================================================== */
    /* public variables ==================================================== */
    /* inline public functions  ============================================ */

  17. #17
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Emmanuel Delahaye
    On est tous d'accord que les variables persistantes modifiables de portée globale sont à éviter. Mais le cas des globales à lecture seule (const) peut simplifier le codage et dans ce cas, une déclaration (extern) suffit. Il n'y a pas de mal à ça.
    Je n'en vois pas l'usage.. Je n'ai jamais vu un exemple où c'était nécessaire, et dans tout Unix/Linux, la seule est errno ....

    Pourrais-tu fournir un exemple ?

    Le problème des variable persistantes statiques n'est pas qu'un problème de portée... C'est aussi et surtout un problème d'instanciation. Pour des données de très haut niveau dont on sait pertinemment qu'elles sont uniques, OK.


    Mais très souvent, on a besoin d'instanciation et dans ce cas, seule l'allocation dynamique est suffisamment souple. Mais j'admets la méthode intermédiaire de l'allocateur manuel (tableau de taille fixe...) si le nombre d'instanciations possibles est limité (par le matériel, notamment).
    là j'avoue que je ne comprends pas ce que tu entends par là..
    sur 2 points : tu dis "très souvent", et tu parles d'instanciations....

    Là encore un exmple aiderait, pour la même raison que ci-dessus...

    En bref je n'ai jamais ni vu utilisé (si une fois, et le code était une horreur... ) ni eu besoin de mettre une variable dans un .h.

    Et pour le problème des statiques, ce que je voulais dire c'est que pour la même raison qu'une routine non déclarée extern ou static peut être écrasée, de la même manière une variable globale à un module mais non déclarée statique peut également être écrasée (il suffit que un autre module déclare extern cette variable, et il en fait ce qu'il veut..). Et que, non seulement doit-on limiter au maximum le nombre de variables globales dans un module, mais encore doit-on également les déclarer statiques..


    On est d'accord...

  18. #18
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    Citation Envoyé par souviron34
    Je n'en vois pas l'usage.. Je n'ai jamais vu un exemple où c'était nécessaire, et dans tout Unix/Linux, la seule est errno ....
    Et on en voit les dégâts tous les jours, notamment si on utilise les threads...

    Mais ce n'est pas une variable à lecture seule. Je parle des tableaux de 'constantes', par exemple (table de sinus, CRC, chaines de caractères etc.)

    là j'avoue que je ne comprends pas ce que tu entends par là..
    sur 2 points : tu dis "très souvent", et tu parles d'instanciations....
    Tu ne comprends pas le mot 'instanciation' ?
    En bref je n'ai jamais ni vu utilisé (si une fois, et le code était une horreur... ) ni eu besoin de mettre une variable dans un .h.
    Définition dans un .h ? Quelle horreur ! Personne n'a parlé de ça.

    (je rappelle qu'on parlait de extern, donc de déclarations dans un .h)

    http://emmanuel-delahaye.developpez....tm#definitions

  19. #19
    Expert confirmé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 610
    Détails du profil
    Informations personnelles :
    Âge : 67
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 610
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Emmanuel Delahaye
    Mais ce n'est pas une variable à lecture seule. Je parle des tableaux de 'constantes', par exemple (table de sinus, CRC, chaines de caractères etc.)
    Ah ok là ça va

    Là oui aucun problème, mais ce ne sont pas des variables à proprement parler... C'est plutôt des constantes, que l'on "ordonne" sous forme de tableaux..

    Cependant même dans ces cas je ne les mettrais pas dans un .h public. Je les mettrais peut-être dans un .h, mais privé, et je ferais une fonction publique qui va les chercher (exemples MySinus(40), GetMyString(id) ).

    Citation Envoyé par -ed-
    Tu ne comprends pas le mot 'instanciation' ?
    Je ne vois pas en quoi ça à a voir pour le genre de problèmes générés ou non par extern, et qui plus est en quoi ça devrait être dans des .h...

    Citation Envoyé par -ed-
    Définition dans un .h ? Quelle horreur ! Personne n'a parlé de ça.

    (je rappelle qu'on parlait de extern, donc de déclarations dans un .h)
    Même dans ce cas, les règles généralement utilisées sont assez claires, et je réitère que je n'en vois pas le besoin.

    Il est certain que les .h peuvent contenir même du code.(en fait même tout le programme ).. Mais les règles de compilation ne sont pas les mêmes que les règles de bonnes manières et le PO en fait demandait si la règle pouvait être évitée..

    J'aimerais juste pour que j'admette que cela est nécessaire que l'on me montre un exemple... Je ne dis pas ça pour faire mauvais ou parce que je suis buté, mais simplement réellement je pense que si on met des variables (même en termes de définitions ) dans un .h c'est qu'il y a un problème de conception..

  20. #20
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Par défaut
    Citation Envoyé par souviron34
    Tout est dans le différent ... Si tu as la même définition, mais un contenu différent, ça ne te jetteras pas, mais ça prendra la dernière linkée.... Donc tout dépendra de l'ordre dans lequel c'est linké, et l'un ou l'autre de toutes façons ne marchera pas correctement...
    J'ai l'impression qu'on ne parle pas tout a fait de la meme chose.
    Qu'entends-tu par "contenu different" ? Parles-tu du code de la fonction ou des parametres de la fonction ?

    Citation Envoyé par souviron34
    C'est le contraire !! SURTOUT PAS de variables dans les .h
    Pourquoi une telle regle aussi rigide ?
    Je suis ok pour ne pas mettre de variable modifiable par n'importe qui dans les .h (je serais meme plutot pour ne pas utiliser de telles variables globales du tout).
    Mais pour une variable globale en lecture seule, il n'y a pas de problemes. Et c'st une alternative de plus en plus frequente et recommandee a #define.


    Citation Envoyé par souviron34
    Si des variables doivent être disponibles à l'extérieur , il faut les passer en paramètres.
    Voir ci-dessus


    Citation Envoyé par souviron34
    Si elles sont globales à ton module, mais non accessibles à l'extérieur, elles doivent être statiques....
    Tout a fait


    Citation Envoyé par souviron34
    Un .h sert à l'extérieur du module, à montrer ce qui est publique...
    Pas uniquement, les .h sont aussi utile a l'interieur d'un module. Notament entre les fichiers composant ce module.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Réponses: 1
    Dernier message: 22/11/2010, 17h00
  2. le mot clef extern ?
    Par ikuzar dans le forum Débuter
    Réponses: 4
    Dernier message: 30/07/2009, 14h50
  3. Deux questions sur le mot clé EXTERN
    Par Bleys dans le forum C++
    Réponses: 4
    Dernier message: 02/03/2008, 14h58
  4. Passage de C++ à Java (mot clef extern)
    Par grodwar dans le forum Langage
    Réponses: 5
    Dernier message: 05/05/2007, 13h06
  5. mot clé extern
    Par salseropom dans le forum C
    Réponses: 2
    Dernier message: 28/06/2006, 09h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo