Re: Who owns the variable in my header file ?

Discussion in 'C Programming' started by hormelfree@gmail.com, Oct 5, 2012.

  1. Guest

    On Thursday, October 4, 2012 7:52:27 AM UTC-7, lipska the kat wrote:
    > On 04/10/12 12:26, David Brown wrote:
    >> On 04/10/2012 12:23, lipska the kat wrote:
    >>> On 03/10/12 19:13, lipska the kat wrote:


    > > [snip] > "foo.c" contains all the implementation.
    > > // foo.h
    > > #ifndef foo_h__
    > > #define foo_h__


    > I don't understand what this means or why you are doing it Can you explain?


    Why, he's making foo.h idempotent, anybody can see that...

    And by idempotent, people who use big words are just trying to
    say that he is only including foo.h once, because he only includes
    it if the macro foo_h__ is not defined...but if it isn't he immediately
    defines it, which is what makes it idempotent. Next time the compiler
    tries to include foo.h for any reason (usually because it is part of
    another .c file's header files in one way or another), the compiler
    (or macro preprocessor) sees the #ifndef for the macro (meaning only
    execute code if the macro is NOT defined), and skips everything until
    the #endif at the bottom of the file...

    This is standard operating procedure for writing units or modules
    or whatever in C, you should always do it to avoid problems later
    on.

    And now you can use the word idempotent to confuse other people...

    ---
    William Ernest Reid
     
    , Oct 5, 2012
    #1
    1. Advertising

  2. Ike Naar Guest

    On 2012-10-05, <> wrote:
    > On Thursday, October 4, 2012 7:52:27 AM UTC-7, lipska the kat wrote:
    >> On 04/10/12 12:26, David Brown wrote:
    >>> On 04/10/2012 12:23, lipska the kat wrote:
    >>>> On 03/10/12 19:13, lipska the kat wrote:

    >
    >> > // foo.h
    >> > #ifndef foo_h__
    >> > #define foo_h__

    >
    >> I don't understand what this means or why you are doing it Can you explain?

    >
    > Why, he's making foo.h idempotent, anybody can see that...


    Picking a nit:
    Some header files don't have to be made idempotent, because they
    already are. The foo.h we are talking about is such a file:

    /* begin foo.h */
    extern int foo;
    void fooset(int);
    int fooget(void);
    void fooinc(void);
    /* end foo.h */

    Including foo.h more than once has the same effect as including it
    once, so the #ifndef-#define trick is not necessary to make
    the file idempotent.
    (it doesn't do any harm either, and it's certainly good practice,
    but in this case it just doesn't make the file more idempotent than
    it already was).

    > And by idempotent, people who use big words are just trying to
    > say that he is only including foo.h once, because he only includes
    > it if the macro foo_h__ is not defined...but if it isn't he immediately
    > defines it, which is what makes it idempotent. Next time the compiler
    > tries to include foo.h for any reason (usually because it is part of
    > another .c file's header files in one way or another), the compiler
    > (or macro preprocessor) sees the #ifndef for the macro (meaning only
    > execute code if the macro is NOT defined), and skips everything until
    > the #endif at the bottom of the file...
     
    Ike Naar, Oct 5, 2012
    #2
    1. Advertising

  3. James Kuyper Guest

    On 10/05/2012 04:11 AM, lipska the kat wrote:
    > On 05/10/12 01:15, wrote:
    >> On Thursday, October 4, 2012 7:52:27 AM UTC-7, lipska the kat wrote:
    >>> On 04/10/12 12:26, David Brown wrote:
    >>>> On 04/10/2012 12:23, lipska the kat wrote:
    >>>>> On 03/10/12 19:13, lipska the kat wrote:

    >>
    >>>> [snip]> "foo.c" contains all the implementation.
    >>>> // foo.h
    >>>> #ifndef foo_h__
    >>>> #define foo_h__

    >>
    >>> I don't understand what this means or why you are doing it Can you explain?

    >>
    >> Why, he's making foo.h idempotent, anybody can see that...

    >
    > Ah, well, you are probably much smarter than I am :)
    >
    >> And by idempotent, people who use big words are just trying to
    >> say that he is only including foo.h once,


    Not precisely. What it means is that including foo.h more than once has
    the same net effect as including it exactly once.

    > I thought this might have something to do with it but I was wondering if
    > the form of thing had any meaning, specifically the way the underscores
    > are used. I have been reading some header files from the glibc libraries
    > and there are underscores all over the place ??? apparently they mean
    > something.


    Trailing underscores have no special meaning. However, leading
    underscores do have a special meaning - in general, identifiers starting
    with an underscore are reserved. Section 7.1.3 explains reserved
    identifiers:

    > 1 Each header declares or defines all identifiers listed in its associated subclause, and
    > optionally declares or defines identifiers listed in its associated future library directions
    > subclause and identifiers which are always reserved either for any use or for use as file
    > scope identifiers.
    > — 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.
    > — Each macro name in any of the following subclauses (including the future library
    > directions) is reserved for use as specified if any of its associated headers is included;
    > unless explicitly stated otherwise (see 7.1.4).
    > — All identifiers with external linkage in any of the following subclauses (including the
    > future library directions) and errno are always reserved for use as identifiers with
    > external linkage.184)
    > — Each identifier with file scope listed in any of the following subclauses (including the
    > future library directions) is reserved for use as a macro name and as an identifier with
    > file scope in the same name space if any of its associated headers is included.
    > 2 No other identifiers are reserved. If the program declares or defines an identifier in a
    > context in which it is reserved (other than as allowed by


    The reason for the existence of reserved identifiers is to prevent
    collisions between identifiers used by the implementation of C, and
    those used by your own code. The identifiers that would give your own
    code undefined behavior if you used them, are precisely the only
    identifiers the standard library can use in contexts where they could
    otherwise conflict with your code. That applies to any identifiers with
    file scope, or macros, that are defined in the standard headers, and
    also to any object or function identifiers with external linkage that
    are part of the standard library. Using reserved identifiers also
    protects the standard headers from being affected by any #defines in
    your own code that occur before #including the standard header.

    glibc is part of the C implementation, and that's why it makes lots of
    use of identifiers starting with underscores.

    Note: if C++ compatibility is of importance to you, then you should also
    avoid double underscores in the middle of an identifier.
    --
    James Kuyper
     
    James Kuyper, Oct 5, 2012
    #3
  4. In article <>,
    Ike Naar <> wrote:
    >
    >Picking a nit:
    >Some header files don't have to be made idempotent, because they
    >already are. The foo.h we are talking about is such a file:


    True, but including header guards (aka "include guard", apparently) is
    best practices. foo.h might not need them *now*, but what if someone
    edits it in the future and doesn't notice that there are no header guards.

    http://en.wikipedia.org/wiki/Include_guard

    Always take a belt-and-suspenders approach. Header guards cost nothing,
    and they can save a lot of debugging pain in the future.

    Remember this, especially for libraries: Just because *your* build
    didn't break, doesn't mean someone else's won't. Maybe foo.h winds up in
    /usr/include someday, and some poor sod of a developer who doesn't have
    root on their own workstation discovers they can't build their project
    any more because some admin installed the latest version of the foo-dev
    package on their system. That's not a far-fetched hypothetical
    either; I've had to deal with it many times in my career.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
     
    Edward A. Falk, Dec 18, 2012
    #4
    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. Eric Sosman

    Re: Who owns the variable in my header file ?

    Eric Sosman, Oct 3, 2012, in forum: C Programming
    Replies:
    46
    Views:
    1,122
    Edward A. Falk
    Dec 19, 2012
  2. Kaz Kylheku

    Re: Who owns the variable in my header file ?

    Kaz Kylheku, Oct 3, 2012, in forum: C Programming
    Replies:
    0
    Views:
    382
    Kaz Kylheku
    Oct 3, 2012
  3. Ike Naar

    Re: Who owns the variable in my header file ?

    Ike Naar, Oct 3, 2012, in forum: C Programming
    Replies:
    0
    Views:
    401
    Ike Naar
    Oct 3, 2012
  4. Edward A. Falk

    Re: Who owns the variable in my header file ?

    Edward A. Falk, Oct 3, 2012, in forum: C Programming
    Replies:
    5
    Views:
    463
    Keith Thompson
    Oct 11, 2012
  5. James Kuyper

    Re: Who owns the variable in my header file ?

    James Kuyper, Oct 4, 2012, in forum: C Programming
    Replies:
    0
    Views:
    312
    James Kuyper
    Oct 4, 2012
Loading...

Share This Page