keyword extern

Discussion in 'C Programming' started by tweak, Jun 26, 2004.

  1. tweak

    tweak Guest

    What's the best way to use extern when using multiplefiles that is
    easiest to maintain?

    Is it best to declare:

    extern int a;

    in a header file and include the header file in all files except
    where it's defined.

    Or is it better to write

    extern int a;

    in all the files except where it's originally defined?

    I'm just curious what the best practice is since I code
    as a hobby. And I'm still learning and making lotsa
    mistakes.

    Thanks,

    Brian

    P.S. Thanks to whomever recommended Advanced Unix Programming
    Second Edition. It's cleared up a lot for me. And it's
    making me question as to whether I should drop linux and
    move to openBSD.
     
    tweak, Jun 26, 2004
    #1
    1. Advertising

  2. In 'comp.lang.c', tweak <> wrote:

    > What's the best way to use extern when using multiplefiles that is
    > easiest to maintain?


    First of all, try to avoid the use of global scope variables. Read-only are
    acceptable, but read/write are source of trouble. However, if you insist ...

    > Is it best to declare:
    >
    > extern int a;
    >
    > in a header file and include the header file in all files except
    > where it's defined.


    Almost. The header should also be included in the definition source file.
    This is the only way to check the match between the declaration and the
    definition.


    /* data.h */
    /* usual guards ommited */
    extern int x;

    /* data.c */
    #include "data.h"
    long x; /* ERR! */

    It also allows nice things like :

    /* data.h */
    /* usual guards ommited */
    extern int a[128];

    /* data.c */
    #include "data.h"
    int a[];

    The size definition is now unique, public and centralized. It helps reading
    and maintenance.

    > Or is it better to write
    >
    > extern int a;
    >
    > in all the files except where it's originally defined?


    Certainly not.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jun 26, 2004
    #2
    1. Advertising

  3. tweak <> wrote in message news:<0a3Dc.3$151.1@fed1read02>...
    > What's the best way to use extern when using multiplefiles that is
    > easiest to maintain?
    >
    > Is it best to declare:
    >
    > extern int a;
    >
    > in a header file and include the header file in all files except
    > where it's defined.
    >
    > Or is it better to write
    >
    > extern int a;
    >
    > in all the files except where it's originally defined?
    >
    > I'm just curious what the best practice is since I code
    > as a hobby. And I'm still learning and making lotsa
    > mistakes.
    >
    > Thanks,
    >
    > Brian
    >
    > P.S. Thanks to whomever recommended Advanced Unix Programming
    > Second Edition. It's cleared up a lot for me. And it's
    > making me question as to whether I should drop linux and
    > move to openBSD.


    Well, my preferred way would be to declare it in all the .c files that
    need the extern variable rather than put the extern declaration in the
    header file and include the header file in the c files. The reason
    being.

    - If the variable was used by all c files, it would be better to make
    it a global variable in the .h file.

    - Keeping the extern declaration in the .c file instead of the .h
    file will make it easier for other .c files that dont need the extern
    variable but need other declarations from the .h file to include it.
     
    Yashesh Bhatia, Jun 26, 2004
    #3
  4. tweak

    Guest

    > What's the best way to use extern when using multiplefiles that is
    > easiest to maintain?


    > Is it best to declare:
    >
    > extern int a;
    >
    > in a header file and include the header file in all files except
    > where it's defined.


    > Or is it better to write
    >
    > extern int a;
    >
    > in all the files except where it's originally defined?


    One of the purposes of using extern in multiple files is restricting
    the visibility of the variable only to the file that needs to "see"
    it. In your question, in both the cases the variable "a" is visible in
    all the files. In such a situation, there is no benefit in using the
    keyword "extern. You might as well declare the variable as global.

    sarma
     
    , Jun 26, 2004
    #4
  5. In 'comp.lang.c', (Yashesh Bhatia) wrote:

    >> Or is it better to write
    >>
    >> extern int a;
    >>
    >> in all the files except where it's originally defined?
    >>

    > Well, my preferred way would be to declare it in all the .c files that
    > need the extern variable rather than put the extern declaration in the
    > header file and include the header file in the c files. The reason
    > being.
    >
    > - If the variable was used by all c files, it would be better to make
    > it a global variable in the .h file.


    No. A header is certainely not the place for an object definition for an
    obvious reason. If you include the header in more than one compile unit, you
    will have more than one definition of the object with the same name. This is
    the kind of situation a linker can't handle, except by an error message.

    > - Keeping the extern declaration in the .c file instead of the .h
    > file will make it easier for other .c files that dont need the extern
    > variable but need other declarations from the .h file to include it.


    The maintainers of such a code will doom you for ever. Please don't do that.
    The OP's first proposal was nearly the good one. Please read my previous
    answer to learn why.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jun 26, 2004
    #5
  6. In 'comp.lang.c', wrote:

    > One of the purposes of using extern in multiple files is restricting
    > the visibility of the variable only to the file that needs to "see"
    > it.


    It certainely is a bad practice. What if the type changes (int to long, float
    to double, etc.) ? Because the compiler has no way to check the consistency
    of the code, if you miss a change the code becomes inconsitent. This practice
    is obviously wrong.

    If you are concerned with the visibility of the global variables, which
    is a good thing, there are other options:

    - don't use global at all. (Use ADT's)
    - give the user no right to change the data (a const pointer to the data)

    /* data.h */
    extern int const *px;

    /* data.c */
    #include "data.h"
    static int x;
    int const *px = &x;

    Of course, in real life, data are gathered in some structure and a single
    'context' pointer is enough.

    Note that this 'protection' is just an intention. There is no way to prevent
    an sloopy programmer to write and compile a code that uses a typecast to
    force the pointer to a read/write access to the data. But it will invoke an
    undefined behaviour. The ADT solution is safer.

    > In your question, in both the cases the variable "a" is visible in
    > all the files. In such a situation, there is no benefit in using the
    > keyword "extern. You might as well declare the variable as global.


    Sorry, I failed to understand your point. 'extern' doesn't make global a
    variable. It's the lack of 'static' that makes it.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jun 26, 2004
    #6
  7. tweak

    Guest

    > > In your question, in both the cases the variable "a" is visible in
    > > all the files. In such a situation, there is no benefit in using the
    > > keyword "extern. You might as well declare the variable as global.

    >
    > Sorry, I failed to understand your point. 'extern' doesn't make global a
    > variable. It's the lack of 'static' that makes it.


    I am sorry if I did not explain myself clearly. If we have the
    following files
    (pseudo-code)

    head.h
    /* common to all files */

    head1.h
    /* used in file1.c */

    file1.c
    include "head.h"
    include "head1.h"
    /* code of file1.c */
    ......

    headN.h
    /* used in fileN.c */

    fileN.c
    include "head.h"
    include "headN.h"
    /* code of fileN.c */

    Now, declare a variable in head1.h as int i and define it in file1.c
    as i = 10. My argument in the above post is, if "i" is declared
    multiple times using extern in all the files file2.c ... fileN.c then
    the significance of "extern"ing is lost. The programmer could have
    acheived the same functionality by declaring the variable in head.h

    sarma
     
    , Jun 26, 2004
    #7
  8. tweak

    tweak Guest

    Emmanuel Delahaye wrote:
    > In 'comp.lang.c', tweak <> wrote:
    >
    >
    >>What's the best way to use extern when using multiplefiles that is
    >>easiest to maintain?

    >
    >
    > First of all, try to avoid the use of global scope variables. Read-only are
    > acceptable, but read/write are source of trouble. However, if you insist ...
    >
    >
    >>Is it best to declare:
    >>
    >>extern int a;
    >>
    >>in a header file and include the header file in all files except
    >>where it's defined.

    >
    >
    > Almost. The header should also be included in the definition source file.
    > This is the only way to check the match between the declaration and the
    > definition.
    >
    >
    > /* data.h */
    > /* usual guards ommited */
    > extern int x;
    >
    > /* data.c */
    > #include "data.h"
    > long x; /* ERR! */
    >
    > It also allows nice things like :
    >
    > /* data.h */
    > /* usual guards ommited */
    > extern int a[128];
    >
    > /* data.c */
    > #include "data.h"
    > int a[];
    >
    > The size definition is now unique, public and centralized. It helps reading
    > and maintenance.


    Thanks. I'm just trying to understand best practice use of the keyword
    extern since I do not program for a living, but I would like to start a
    project at source forge this year. And I am just double checking the
    basics.

    So the best practice would be to use global static variables in practice
    rather than modifiable extern variables? How should extern be used then?

    And structures are preferred when appropriate?

    Thanks,

    Brian
     
    tweak, Jun 26, 2004
    #8
  9. tweak

    Jack Klein Guest

    On Sat, 26 Jun 2004 10:19:23 -0700, tweak <> wrote
    in comp.lang.c:

    > Emmanuel Delahaye wrote:
    > > In 'comp.lang.c', tweak <> wrote:
    > >
    > >
    > >>What's the best way to use extern when using multiplefiles that is
    > >>easiest to maintain?

    > >
    > >
    > > First of all, try to avoid the use of global scope variables. Read-only are
    > > acceptable, but read/write are source of trouble. However, if you insist ...
    > >
    > >
    > >>Is it best to declare:
    > >>
    > >>extern int a;
    > >>
    > >>in a header file and include the header file in all files except
    > >>where it's defined.

    > >
    > >
    > > Almost. The header should also be included in the definition source file.
    > > This is the only way to check the match between the declaration and the
    > > definition.
    > >
    > >
    > > /* data.h */
    > > /* usual guards ommited */
    > > extern int x;
    > >
    > > /* data.c */
    > > #include "data.h"
    > > long x; /* ERR! */
    > >
    > > It also allows nice things like :
    > >
    > > /* data.h */
    > > /* usual guards ommited */
    > > extern int a[128];
    > >
    > > /* data.c */
    > > #include "data.h"
    > > int a[];
    > >
    > > The size definition is now unique, public and centralized. It helps reading
    > > and maintenance.

    >
    > Thanks. I'm just trying to understand best practice use of the keyword
    > extern since I do not program for a living, but I would like to start a
    > project at source forge this year. And I am just double checking the
    > basics.
    >
    > So the best practice would be to use global static variables in practice


    Note that the word "global" does not exist in the C standard. The
    term you are looking for here is "file scope" which is well defined by
    the C standard.

    All declarations and definitions written outside of any function in a
    file have "file scope". Their scope lasts from the point of the
    definition or declaration until the end of the translation unit being
    compiled.

    File scope definitions and declarations have external linkage by
    default, unless the keyword static is added.

    One never needs to use the extern keyword with a function definition,
    prototype or declaration. All references to functions have external
    linkage by default.

    One needs to us the extern keyword for declarations (not definitions)
    of data objects that are defined elsewhere. That is because of the
    tentative definition feature in C.

    If, outside of any block in a file, you have the three file scope
    declarations:

    extern int x;
    int y = 0;
    int z;

    ....then here is how a C compiler understands them.

    -- extern int x; If there is no other file scope declaration of this
    object in the source file, the compiler will treat it as a simple
    external declaration. If any code in the source file access 'x', the
    compiler will generate an external reference for it. In the final
    stage of creating the executable program, usually called linking, the
    int 'x' must be provided by another source file or library.

    -- int y = 0; This is a definition of an int named 'y' that has
    static storage duration, external linkage, and file scope. It will be
    initialized with the value 0 before main() is called, and its lifetime
    will be the entire execution time of the program. Even if none of the
    code in the source file access 'y', the compiler will generate an
    external definition for it. If there is more than one external
    definition of this object in the final program, the result is
    undefined.

    --- int z; This is a 'tentative definition'. If there is no other
    declaration for this object, then at the end of the file the compiler
    will automatically create a definition "int z = 0'" and create the
    object.

    > rather than modifiable extern variables? How should extern be used then?


    As to the use of variables with external linkage, modifiable or not, I
    will say this: All absolute rules are rubbish, including this one.

    Modifiable objects with wide scope, whether they have external linkage
    or not, can be and often are abused and become the cause of hard to
    find program defects. Nevertheless, like almost every other feature
    of the language, they can be used properly and sometimes they are the
    best solution to a problem. On the other hand, many times there are
    better solutions possible.

    > And structures are preferred when appropriate?
    >
    > Thanks,
    >
    > Brian


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jun 26, 2004
    #9
  10. tweak

    Minti Guest

    Emmanuel Delahaye <> wrote in message news:<Xns951474F0A1393hsnoservernet@212.27.42.72>...
    > In 'comp.lang.c', wrote:
    >
    > > One of the purposes of using extern in multiple files is restricting
    > > the visibility of the variable only to the file that needs to "see"
    > > it.

    >
    > It certainely is a bad practice. What if the type changes (int to long, float
    > to double, etc.) ? Because the compiler has no way to check the consistency
    > of the code, if you miss a change the code becomes inconsitent. This practice
    > is obviously wrong.
    >
    > If you are concerned with the visibility of the global variables, which
    > is a good thing, there are other options:
    >
    > - don't use global at all. (Use ADT's)


    Could you elucidate this point?

    --
    Imanpreet Singh Arora
    isingh AT acm DOT org
     
    Minti, Jun 26, 2004
    #10
  11. tweak

    tweak Guest

    Jack Klein wrote:
    > On Sat, 26 Jun 2004 10:19:23 -0700, tweak <> wrote
    > in comp.lang.c:
    >
    >
    >>Emmanuel Delahaye wrote:
    >>
    >>>In 'comp.lang.c', tweak <> wrote:
    >>>
    >>>
    >>>
    >>>>What's the best way to use extern when using multiplefiles that is
    >>>>easiest to maintain?
    >>>
    >>>
    >>>First of all, try to avoid the use of global scope variables. Read-only are
    >>>acceptable, but read/write are source of trouble. However, if you insist ...
    >>>
    >>>
    >>>
    >>>>Is it best to declare:
    >>>>
    >>>>extern int a;
    >>>>
    >>>>in a header file and include the header file in all files except
    >>>>where it's defined.
    >>>
    >>>
    >>>Almost. The header should also be included in the definition source file.
    >>>This is the only way to check the match between the declaration and the
    >>>definition.
    >>>
    >>>
    >>>/* data.h */
    >>>/* usual guards ommited */
    >>>extern int x;
    >>>
    >>>/* data.c */
    >>>#include "data.h"
    >>>long x; /* ERR! */
    >>>
    >>>It also allows nice things like :
    >>>
    >>>/* data.h */
    >>>/* usual guards ommited */
    >>>extern int a[128];
    >>>
    >>>/* data.c */
    >>>#include "data.h"
    >>>int a[];
    >>>
    >>>The size definition is now unique, public and centralized. It helps reading
    >>>and maintenance.

    >>
    >>Thanks. I'm just trying to understand best practice use of the keyword
    >>extern since I do not program for a living, but I would like to start a
    >>project at source forge this year. And I am just double checking the
    >>basics.
    >>
    >>So the best practice would be to use global static variables in practice

    >
    >
    > Note that the word "global" does not exist in the C standard. The
    > term you are looking for here is "file scope" which is well defined by
    > the C standard.
    >
    > All declarations and definitions written outside of any function in a
    > file have "file scope". Their scope lasts from the point of the
    > definition or declaration until the end of the translation unit being
    > compiled.
    >
    > File scope definitions and declarations have external linkage by
    > default, unless the keyword static is added.
    >
    > One never needs to use the extern keyword with a function definition,
    > prototype or declaration. All references to functions have external
    > linkage by default.
    >
    > One needs to us the extern keyword for declarations (not definitions)
    > of data objects that are defined elsewhere. That is because of the
    > tentative definition feature in C.
    >
    > If, outside of any block in a file, you have the three file scope
    > declarations:
    >
    > extern int x;
    > int y = 0;
    > int z;
    >
    > ...then here is how a C compiler understands them.
    >
    > -- extern int x; If there is no other file scope declaration of this
    > object in the source file, the compiler will treat it as a simple
    > external declaration. If any code in the source file access 'x', the
    > compiler will generate an external reference for it. In the final
    > stage of creating the executable program, usually called linking, the
    > int 'x' must be provided by another source file or library.
    >
    > -- int y = 0; This is a definition of an int named 'y' that has
    > static storage duration, external linkage, and file scope. It will be
    > initialized with the value 0 before main() is called, and its lifetime
    > will be the entire execution time of the program. Even if none of the
    > code in the source file access 'y', the compiler will generate an
    > external definition for it. If there is more than one external
    > definition of this object in the final program, the result is
    > undefined.
    >
    > --- int z; This is a 'tentative definition'. If there is no other
    > declaration for this object, then at the end of the file the compiler
    > will automatically create a definition "int z = 0'" and create the
    > object.
    >
    >
    >>rather than modifiable extern variables? How should extern be used then?

    >
    >
    > As to the use of variables with external linkage, modifiable or not, I
    > will say this: All absolute rules are rubbish, including this one.
    >
    > Modifiable objects with wide scope, whether they have external linkage
    > or not, can be and often are abused and become the cause of hard to
    > find program defects. Nevertheless, like almost every other feature
    > of the language, they can be used properly and sometimes they are the
    > best solution to a problem. On the other hand, many times there are
    > better solutions possible.


    Thanks for being very clear.

    I am trying to avoid problems of maintenance before I finish writing my
    project. I see too many open source projects, where I cannot easily
    navigate through the code, and I'm trying to avoid that from the onset.

    I saw extern as being a probable maintenance problem since tracking down
    definitions has never been any fun.

    Thanks Again,

    Brian

    P.S. I'm still learning.
     
    tweak, Jun 26, 2004
    #11
  12. tweak

    CBFalconer Guest

    wrote: (and stripped all attributions)
    >
    >>> In your question, in both the cases the variable "a" is visible in
    >>> all the files. In such a situation, there is no benefit in using the
    >>> keyword "extern. You might as well declare the variable as global.

    >>
    >> Sorry, I failed to understand your point. 'extern' doesn't make
    >> global a variable. It's the lack of 'static' that makes it.

    >
    > I am sorry if I did not explain myself clearly. If we have the
    > following files
    > (pseudo-code)
    >
    > head.h
    > /* common to all files */
    >
    > head1.h
    > /* used in file1.c */
    >
    > file1.c
    > include "head.h"
    > include "head1.h"
    > /* code of file1.c */
    > .....
    >
    > headN.h
    > /* used in fileN.c */
    >
    > fileN.c
    > include "head.h"
    > include "headN.h"
    > /* code of fileN.c */
    >
    > Now, declare a variable in head1.h as int i and define it in
    > file1.c as i = 10. My argument in the above post is, if "i" is
    > declared multiple times using extern in all the files file2.c
    > ... fileN.c then the significance of "extern"ing is lost. The
    > programmer could have acheived the same functionality by
    > declaring the variable in head.h


    NEVER, ever, define a variable in a header file. Define it in the
    ..c file where it most naturally belongs. If this is a 'global'
    variable, omit the "static" qualifier, otherwise include it for
    all file scope variables. To make it available in other files
    declare it with the "extern" qualifier in the header file for the
    ..c file in which defined.

    Remember, the purpose of header files is to make something in the
    ..c file accessible to other .c files. Nothing more or less. The
    fact that #include can be misused in various ways does not affect
    this.

    The very presence above of a head.h common to all files suggests
    misuse. A variable visible in another file is subject to
    accidental modification by a typo, or simply failing to remember
    something obscure. Minimize and control scope as far as possible.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jun 26, 2004
    #12
  13. In 'comp.lang.c', (Minti) wrote:

    >> - don't use global at all. (Use ADT's)

    >
    > Could you elucidate this point?


    I assume you meant 'elaborate'. Well, it's a piece of cake...

    In a few words, Abstract Data Types (ADT) allow the process of some data
    being kind of anonymous from the user pof view. All the processes are
    implemented by functions : Creators, Deletors, Accessors, Processors etc.

    A good example is given by the implementation of the streams in C.

    You have the type FILE. Its inner description in not specified by the
    language, but obviously, the user has not to know about the details. This is
    an Abstract Data Type.

    You have a creator : feopen() that creates an instance of a FILE object
    according to the parameters, and returns the address of it. Of course, the
    the address must be stored into a pointer of the same type for future use :

    FILE *fp = fopen (...);

    Then, you have the deletor fclose(). You just pass the address of the object,
    and it will do the job.

    fclose (fp);

    You have processors like fread(), fwrite() etc, accessors, like feof() etc.

    One way to make the data invisible from the user is share the definition of
    the structure in two parts :

    The public part is anonymous:

    struct my_adt;

    or

    typedef struct my_adt my_adt_s;

    for typesavers like me. It belongs to the interface (header: .h).

    the other part is private. It holds the complete definition of the object.

    struct my_adt
    {
    /* inner details */
    };

    it belongs to the implementation (source: .c).

    Of course, creation/deletion implies the use of malloc()/free(), as you
    guessed...

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jun 27, 2004
    #13
  14. tweak

    John Ilves Guest

    tweak wrote:
    > Jack Klein wrote:
    >
    >> On Sat, 26 Jun 2004 10:19:23 -0700, tweak <> wrote
    >> in comp.lang.c:
    >>
    >>
    >>> Emmanuel Delahaye wrote:
    >>>
    >>>> In 'comp.lang.c', tweak <> wrote:
    >>>>
    >>>>
    >>>>
    >>>>> What's the best way to use extern when using multiplefiles that is
    >>>>> easiest to maintain?
    >>>>
    >>>>
    >>>>
    >>>> First of all, try to avoid the use of global scope variables.
    >>>> Read-only are acceptable, but read/write are source of trouble.
    >>>> However, if you insist ...
    >>>>
    >>>>
    >>>>
    >>>>> Is it best to declare:
    >>>>>
    >>>>> extern int a;
    >>>>>
    >>>>> in a header file and include the header file in all files except
    >>>>> where it's defined.
    >>>>
    >>>>
    >>>>
    >>>> Almost. The header should also be included in the definition source
    >>>> file. This is the only way to check the match between the
    >>>> declaration and the definition.
    >>>>
    >>>> /* data.h */
    >>>> /* usual guards ommited */
    >>>> extern int x;
    >>>> /* data.c */
    >>>> #include "data.h"
    >>>> long x; /* ERR! */
    >>>>
    >>>> It also allows nice things like :
    >>>>
    >>>> /* data.h */
    >>>> /* usual guards ommited */
    >>>> extern int a[128];
    >>>> /* data.c */
    >>>> #include "data.h"
    >>>> int a[];
    >>>>
    >>>> The size definition is now unique, public and centralized. It helps
    >>>> reading and maintenance.
    >>>
    >>>
    >>> Thanks. I'm just trying to understand best practice use of the
    >>> keyword extern since I do not program for a living, but I would like
    >>> to start a project at source forge this year. And I am just double
    >>> checking the basics.
    >>>
    >>> So the best practice would be to use global static variables in practice

    >>
    >>
    >>
    >> Note that the word "global" does not exist in the C standard. The
    >> term you are looking for here is "file scope" which is well defined by
    >> the C standard.
    >>
    >> All declarations and definitions written outside of any function in a
    >> file have "file scope". Their scope lasts from the point of the
    >> definition or declaration until the end of the translation unit being
    >> compiled.
    >>
    >> File scope definitions and declarations have external linkage by
    >> default, unless the keyword static is added.
    >>
    >> One never needs to use the extern keyword with a function definition,
    >> prototype or declaration. All references to functions have external
    >> linkage by default.
    >>
    >> One needs to us the extern keyword for declarations (not definitions)
    >> of data objects that are defined elsewhere. That is because of the
    >> tentative definition feature in C.
    >>
    >> If, outside of any block in a file, you have the three file scope
    >> declarations:
    >>
    >> extern int x;
    >> int y = 0;
    >> int z;
    >>
    >> ...then here is how a C compiler understands them.
    >>
    >> -- extern int x; If there is no other file scope declaration of this
    >> object in the source file, the compiler will treat it as a simple
    >> external declaration. If any code in the source file access 'x', the
    >> compiler will generate an external reference for it. In the final
    >> stage of creating the executable program, usually called linking, the
    >> int 'x' must be provided by another source file or library.
    >>
    >> -- int y = 0; This is a definition of an int named 'y' that has
    >> static storage duration, external linkage, and file scope. It will be
    >> initialized with the value 0 before main() is called, and its lifetime
    >> will be the entire execution time of the program. Even if none of the
    >> code in the source file access 'y', the compiler will generate an
    >> external definition for it. If there is more than one external
    >> definition of this object in the final program, the result is
    >> undefined.
    >>
    >> --- int z; This is a 'tentative definition'. If there is no other
    >> declaration for this object, then at the end of the file the compiler
    >> will automatically create a definition "int z = 0'" and create the
    >> object.
    >>
    >>
    >>> rather than modifiable extern variables? How should extern be used
    >>> then?

    >>
    >>
    >>
    >> As to the use of variables with external linkage, modifiable or not, I
    >> will say this: All absolute rules are rubbish, including this one.
    >>
    >> Modifiable objects with wide scope, whether they have external linkage
    >> or not, can be and often are abused and become the cause of hard to
    >> find program defects. Nevertheless, like almost every other feature
    >> of the language, they can be used properly and sometimes they are the
    >> best solution to a problem. On the other hand, many times there are
    >> better solutions possible.

    >
    >
    > Thanks for being very clear.
    >
    > I am trying to avoid problems of maintenance before I finish writing my
    > project. I see too many open source projects, where I cannot easily
    > navigate through the code, and I'm trying to avoid that from the onset.
    >
    > I saw extern as being a probable maintenance problem since tracking down
    > definitions has never been any fun.


    Thought I'd mention that cscope can be very useful for that:
    http://cscope.sourceforge.net/

    >
    > Thanks Again,
    >
    > Brian
    >
    > P.S. I'm still learning.
     
    John Ilves, Jun 27, 2004
    #14
  15. tweak

    Dan Pop Guest

    In <Xns95146180E97EAhsnoservernet@212.27.42.72> Emmanuel Delahaye <> writes:

    >In 'comp.lang.c', tweak <> wrote:
    >
    >> What's the best way to use extern when using multiplefiles that is
    >> easiest to maintain?

    >
    >First of all, try to avoid the use of global scope variables. Read-only are
    >acceptable, but read/write are source of trouble. However, if you insist ...


    In incompetent hands, read/write globals can be, indeed, a source of
    trouble. If you know what you're doing, they work just fine.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 28, 2004
    #15
  16. tweak

    Dan Pop Guest

    In <cgiDc.1466$151.1398@fed1read02> tweak <> writes:

    >So the best practice would be to use global static variables in practice
    >rather than modifiable extern variables? How should extern be used then?
    >
    >And structures are preferred when appropriate?


    The first rule you have to learn about computer programming in general is
    that what is best depends exclusively on your application and your skills.
    What is best for an application is not necessarily best for another and
    what is best for a professional programmer is not necessarily best for a
    beginner.

    It is you and only you who can decide the best solution and it's better
    to avoid any religious rules.

    WRT your original question: when you need to share a global variable,
    you declare it as extern in a common header that is included by all the
    files using that variable, *including* the one that actually contains
    its definition (to be sure that there are no conflicts between the
    common declaration and the private definition). It's not impossible to
    change one of them, but forget to change the other accordingly and this
    safety measure has no extra costs or strings attached.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 28, 2004
    #16
  17. tweak

    Dan Pop Guest

    In <> (Minti) writes:

    >Emmanuel Delahaye <> wrote in message news:<Xns951474F0A1393hsnoservernet@212.27.42.72>...
    >> In 'comp.lang.c', wrote:
    >>
    >> > One of the purposes of using extern in multiple files is restricting
    >> > the visibility of the variable only to the file that needs to "see"
    >> > it.

    >>
    >> It certainely is a bad practice. What if the type changes (int to long, float
    >> to double, etc.) ? Because the compiler has no way to check the consistency
    >> of the code, if you miss a change the code becomes inconsitent. This practice
    >> is obviously wrong.
    >>
    >> If you are concerned with the visibility of the global variables, which
    >> is a good thing, there are other options:
    >>
    >> - don't use global at all. (Use ADT's)

    >
    >Could you elucidate this point?


    No need to, as it's a religious issue.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 28, 2004
    #17
  18. In 'comp.lang.c', (Dan Pop) wrote:

    >>> - don't use global at all. (Use ADT's)

    >>
    >>Could you elucidate this point?

    >
    > No need to, as it's a religious issue.


    Noone care about your opinion. BTW, that's unfair. You quote a single line
    that was part of an alternative.

    <quote="-ed-">
    If you are concerned with the visibility of the global variables, which
    is a good thing, there are other options:

    - don't use global at all. (Use ADT's)
    - give the user no right to change the data (a const pointer to the data)
    </quote>

    Don't you have more interesting things to do than trying to tease me? You are
    so good at technical matters. Stick to it.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jun 28, 2004
    #18
  19. tweak

    Dan Pop Guest

    In <Xns9516DDC80CD61hsnoservernet@212.27.42.74> Emmanuel Delahaye <> writes:

    >In 'comp.lang.c', (Dan Pop) wrote:
    >
    >>>> - don't use global at all. (Use ADT's)
    >>>
    >>>Could you elucidate this point?

    >>
    >> No need to, as it's a religious issue.

    >
    >Noone care about your opinion.


    Then, I everybody should have already plonked me. Makes me wonder why
    do so many people reply to my posts...

    And if *you* don't care about my opinion (or are you the exception to
    your own statement?), why do you read my posts?

    >Don't you have more interesting things to do than trying to tease me?


    It's not a matter of teasing you, it's a matter of debunking your
    religion presented as technical advice.

    >You are so good at technical matters. Stick to it.


    When I need your advice, I'll kindly ask for it.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 29, 2004
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Matthews
    Replies:
    5
    Views:
    2,555
    tom_usenet
    Aug 2, 2004
  2. ooze

    how to use the keyword extern in c?

    ooze, Aug 25, 2004, in forum: C Programming
    Replies:
    16
    Views:
    669
    Dan Pop
    Aug 30, 2004
  3. siliconwafer

    Use of 'extern' keyword

    siliconwafer, Jul 28, 2005, in forum: C Programming
    Replies:
    5
    Views:
    403
    Kenny McCormack
    Jul 31, 2005
  4. Seeker

    extern keyword

    Seeker, Jun 29, 2006, in forum: C Programming
    Replies:
    5
    Views:
    436
    Seeker
    Jul 3, 2006
  5. Andre
    Replies:
    5
    Views:
    565
    Keith Thompson
    Jul 17, 2012
Loading...

Share This Page