Do we need to continue to include stdio.h in C files ?

Discussion in 'C Programming' started by karthikbalaguru, Mar 7, 2009.

  1. Hi,

    The #include tells the compiler to include information
    about the standard input/ouput library and this appears
    in many source files.

    But, why cannot C link the libraries using the linkers
    automatically during linking procedure instead of having these
    #includes ?

    Thx in advans,
    Karthik Balaguru
     
    karthikbalaguru, Mar 7, 2009
    #1
    1. Advertising

  2. karthikbalaguru

    James Kuyper Guest

    karthikbalaguru wrote:
    > Hi,
    >
    > The #include tells the compiler to include information
    > about the standard input/ouput library and this appears
    > in many source files.
    >
    > But, why cannot C link the libraries using the linkers
    > automatically during linking procedure instead of having these
    > #includes ?


    The standard headers serve an entirely different purpose from the
    corresponding libraries. The standard headers provide declarations and
    definitions for various identifiers that your program needs to know
    about in order to make use of the corresponding library, things that the
    compiler needs to know about long before the link phase. The identifiers
    include type names, macros, function names, and object names.
     
    James Kuyper, Mar 7, 2009
    #2
    1. Advertising

  3. On Fri, 6 Mar 2009 20:55:59 -0800 (PST), karthikbalaguru
    <> wrote:

    >Hi,
    >
    >The #include tells the compiler to include information
    >about the standard input/ouput library and this appears
    >in many source files.
    >
    >But, why cannot C link the libraries using the linkers
    >automatically during linking procedure instead of having these
    >#includes ?


    #include has nothing to with linking as others have explained.

    Consider the situation where a particular compiler implementer decided
    to include all the details of stdio.h in the compiler so that
    including stdio.h was redundant. As a user of that particular
    compiler, you get out of the habit of including stdio.h.

    When the next version of the standard comes out, something in stdio.h
    changes. Something simple like a fourth SEEK_ macro. Under normal
    conditions, this change would not require any compiler changes. Those
    who include the new stdio.h would be able to use the new macro
    immediately. (Yes fseek must change to deal with the new value but
    that is not a compiler change.) You, however, will receive
    diagnostics regarding the unknown name. You either start including
    the new stdio.h (defeating the built-in feature) or wait for the
    compiler writer to add the new macro to the compiler itself.

    Like most other programmers, compiler writers are not usually fond of
    make-work. Considering the almost non-existent return on investment,
    the effort to put stdio.h into the compiler is just isn't worth it.
    And why stop at stdio.h? Why not stdlib.h also? And then math.h?
    etc.

    --
    Remove del for email
     
    Barry Schwarz, Mar 7, 2009
    #3
  4. karthikbalaguru

    Bartc Guest

    "Barry Schwarz" <> wrote in message
    news:...
    > On Fri, 6 Mar 2009 20:55:59 -0800 (PST), karthikbalaguru
    > <> wrote:
    >
    >>Hi,
    >>
    >>The #include tells the compiler to include information
    >>about the standard input/ouput library and this appears
    >>in many source files.
    >>
    >>But, why cannot C link the libraries using the linkers
    >>automatically during linking procedure instead of having these
    >>#includes ?

    >
    > #include has nothing to with linking as others have explained.
    >
    > Consider the situation where a particular compiler implementer decided
    > to include all the details of stdio.h in the compiler so that
    > including stdio.h was redundant. As a user of that particular
    > compiler, you get out of the habit of including stdio.h.
    > When the next version of the standard comes out, something in stdio.h
    > changes. Something simple like a fourth SEEK_ macro. Under normal
    > conditions, this change would not require any compiler changes. Those
    > who include the new stdio.h would be able to use the new macro
    > immediately.


    The compiler could just implicitly include stdio.h, which would have (likely
    already has) guards so that an extra #include <stdio.h> would not be
    detrimental.

    But where would the new stdio.h come from anyway?

    > Like most other programmers, compiler writers are not usually fond of
    > make-work. Considering the almost non-existent return on investment,
    > the effort to put stdio.h into the compiler is just isn't worth it.
    > And why stop at stdio.h? Why not stdlib.h also? And then math.h?
    > etc.


    That's a good idea; there are a couple of dozen standard headers but they
    don't amount to that much code. Just include the lot automatically. Or have
    one super header #include <clib.h> in the same there is #include
    <windows.h>.

    If the standard library was spread over 200 standard headers instead of
    about 20, it's easy to see the present situation is almost ridiculous.

    --
    Bartc
     
    Bartc, Mar 8, 2009
    #4
  5. karthikbalaguru

    James Kuyper Guest

    pete wrote:
    ....
    > K&R C had just one standard header, <stdio.h>.


    I learned C very shortly after K&R I first came out. I remember thinking
    "If almost every non-trivial C program requires #include <stdio.h>, why
    don't they just make it implicit?".
     
    James Kuyper, Mar 9, 2009
    #5
  6. karthikbalaguru

    Stefan Ram Guest

    James Kuyper <> writes:
    >I learned C very shortly after K&R I first came out. I remember thinking
    >"If almost every non-trivial C program requires #include <stdio.h>, why
    >don't they just make it implicit?".


    Have you since changed your thinking?
     
    Stefan Ram, Mar 9, 2009
    #6
  7. karthikbalaguru

    Bartc Guest

    "James Kuyper" <> wrote in message
    news:AP7tl.2161$%...
    > pete wrote:
    > ...
    >> K&R C had just one standard header, <stdio.h>.

    >
    > I learned C very shortly after K&R I first came out. I remember thinking
    > "If almost every non-trivial C program requires #include <stdio.h>, why
    > don't they just make it implicit?".


    Probably almost every trivial program too.

    Is there any program, that does any useful work, that doesn't need stdio.h?

    --
    Bartc
     
    Bartc, Mar 9, 2009
    #7
  8. karthikbalaguru

    Willem Guest

    Bartc wrote:
    ) Is there any program, that does any useful work, that doesn't need stdio.h?

    No, but there are bound to be plenty of modules that don't.
    Most C programs tend to have more than one source file, you know.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Mar 9, 2009
    #8
  9. karthikbalaguru

    James Kuyper Guest

    Stefan Ram wrote:
    > James Kuyper <> writes:
    >> I learned C very shortly after K&R I first came out. I remember thinking
    >> "If almost every non-trivial C program requires #include <stdio.h>, why
    >> don't they just make it implicit?".

    >
    > Have you since changed your thinking?


    As long as <stdio.h> was the only header required by the entire standard
    library, I think that was a legitimate question. I can't remember being
    aware of the fact that additional headers were added later. As a result,
    I was surprised when pete pointed out that K&R c only used <stdio.h>.
    However, I checked my copy of K&R I, and he's right.

    I now believe that using multiple headers for a sufficiently large
    library was a good idea for two different reasons, one that is obsolete,
    and one that is not.

    The obsolete reason is that it reduced the compilation time by a
    significant amount if you only #included the headers that you actually
    needed. Computers have gotten a lot faster since then, and I doubt that
    many people compile code on machines with such severe limitations. I
    believe that some people do compile code for such machines, but that
    they usually use a cross-compiler to do so.

    The reason that still applies is name space pollution. As libraries
    (standard and otherwise) continue to proliferate, I shouldn't have to be
    aware of the hundreds (or even thousands) of different identifiers that
    are in use by all of those libraries, so I can avoid using them in a
    conflicting way in my program. I should only have to worry about the
    identifiers used by the parts of those libraries that I'm actually using.

    Having a separate header for each part of the library helps reduce this
    problem. It doesn't avoid the problem completely: you still can't use,
    as an identifier with external linkage, any identifier that the C
    standard lists as an identifier with external linkage in any part of the
    C standard libraries, regardless of whether or not you #include the
    corresponding header.
     
    James Kuyper, Mar 9, 2009
    #9
  10. karthikbalaguru

    James Kuyper Guest

    Bartc wrote:
    >
    > "James Kuyper" <> wrote in message
    > news:AP7tl.2161$%...
    >> pete wrote:
    >> ...
    >>> K&R C had just one standard header, <stdio.h>.

    >>
    >> I learned C very shortly after K&R I first came out. I remember
    >> thinking "If almost every non-trivial C program requires #include
    >> <stdio.h>, why don't they just make it implicit?".

    >
    > Probably almost every trivial program too.
    >
    > Is there any program, that does any useful work, that doesn't need stdio.h?


    I've written one or two programs that did nothing but perform a useful
    calculation involving numbers that were included in the source code, and
    returned an exit value which told me whether or not the result of the
    calculation met a specific criterion. These programs made no use of any
    library routines. However, I've only done that a few times in the 33
    years I've been programming.
     
    James Kuyper, Mar 9, 2009
    #10
  11. karthikbalaguru

    Guest

    Subject: "Do we need to continue to include stdio.h in C files ?"

    yes


    On 7 Mar, 04:55, karthikbalaguru <> wrote:

    > The #include tells the compiler to include information
    > about the standard input/ouput library and this appears
    > in many source files.
    >
    > But, why cannot C link the libraries using the linkers
    > automatically during linking procedure instead of having these
    > #includes ?


    now who was it that said distinguishing headers from
    libraries was pedantic? And that newbies weren't confused...
     
    , Mar 9, 2009
    #11
  12. karthikbalaguru

    Stefan Ram Guest

    James Kuyper <> writes:
    >The obsolete reason is that it reduced the compilation time by a
    >significant amount if you only #included the headers that you actually


    When a build gets large enough or when one is going through
    several edit-build-test cycles, this still might be relevant.

    Always including »stdio.h« also might be of no use when one is
    using a freestanding implementation of C or when one is using
    C to write system programs or applications using calls to an
    operating system's API. It also might be possible that a
    freestanding implementation uses a library that wants to
    define its own meaning for common identifiers such as »FILE«.
     
    Stefan Ram, Mar 9, 2009
    #12
  13. In article <AP7tl.2161$%>,
    James Kuyper <> wrote:

    >I learned C very shortly after K&R I first came out. I remember thinking
    >"If almost every non-trivial C program requires #include <stdio.h>, why
    >don't they just make it implicit?".


    I think it's more accurate to say that almost every trivial C program
    needs <stdio.h>. Most non-trivial C programs only need it in some of
    the files.

    And of course programs not written entirely in standard C may use
    quite other methods for i/o.

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
     
    Richard Tobin, Mar 9, 2009
    #13
  14. karthikbalaguru

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >James Kuyper <> writes:
    >>The obsolete reason is that it reduced the compilation time by a
    >>significant amount if you only #included the headers that you actually

    >When a build gets large enough or when one is going through
    >several edit-build-test cycles, this still might be relevant.
    >Always including »stdio.h« also might be of no use when one is


    Also, »#include <stdio.h«, »#include <cstdio>« (sorry!),
    »#include <windows.h>« at the start of a source file can
    double as a kind of documentation, giving the experienced
    reader an immediate idea of what kind of program this is.
     
    Stefan Ram, Mar 9, 2009
    #14
  15. karthikbalaguru

    Bartc Guest

    "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > James Kuyper <> writes:
    >>The obsolete reason is that it reduced the compilation time by a
    >>significant amount if you only #included the headers that you actually

    >
    > When a build gets large enough or when one is going through
    > several edit-build-test cycles, this still might be relevant.
    >
    > Always including »stdio.h« also might be of no use when one is
    > using a freestanding implementation of C or when one is using
    > C to write system programs or applications using calls to an


    For some of us C's approach seems a little old-fashioned.

    Imagine if all C's standard types, operators and keywords were partitioned
    into sets and each set needed a header, and you always had to be aware of
    which sets were being used and which headers needed to be declared.

    It would be a nuisance, which is the case with many of the extra types,
    constants and functions that other languages have built-in but C chooses to
    put into headers.

    (I wouldn't have thought that always including stdio.h, or any of the
    standard headers, would cause any additional resources to be used in the
    final executable.)

    > operating system's API. It also might be possible that a
    > freestanding implementation uses a library that wants to
    > define its own meaning for common identifiers such as »FILE«.


    It sounds unusual enough to warrant special actions when needed, rather than
    the other way round (meaning 99% explicit inclusion of stdio.h just so the
    other 1% can redefine what's in stdio.h).

    (The answer of course is being able to deal with multiple levels of symbols
    in include files, but C's preprocessor system is too crude to deal with
    this. However the less useful extra scopes inside blocks do seem to be
    available (in C99?).)

    --
    Bartc
     
    Bartc, Mar 9, 2009
    #15
  16. In article <Ls9tl.4871$> "Bartc" <> writes:
    ....
    > It would be a nuisance, which is the case with many of the extra types,
    > constants and functions that other languages have built-in but C chooses to
    > put into headers.


    Algol 68 also had the extra types, constants and functions not built-in in
    the compiler. I have used an Algol 68 compiler where you could compile
    with or without the standard environment. Compiling without was necessary
    when compiling the standard environment itself.
    --
    dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
     
    Dik T. Winter, Mar 9, 2009
    #16
  17. karthikbalaguru

    Guest

    On 9 Mar, 12:56, "Bartc" <> wrote:
    > "James Kuyper" <> wrote in message
    > news:AP7tl.2161$%...
    > > pete wrote:



    > >> K&R C had just one standard header, <stdio.h>.

    >
    > > I learned C very shortly after K&R I first came out. I remember thinking
    > > "If almost every non-trivial C program requires #include <stdio.h>, why
    > > don't they just make it implicit?".

    >
    > Probably almost every trivial program too.
    >
    > Is there any program, that does any useful work, that doesn't need stdio.h?


    I don't think I've actually seen one, but I've seen ones that come
    close.
    These tend to be server type applications that did all their i/o via
    sockets. If there was a GUI or other user interface it communicated
    with that via a socket. Hence 90% of the i/o was not via stdio. Where
    this broke down was reading configuration files, logging errors and
    startup and shutdown messages.
     
    , Mar 9, 2009
    #17
  18. (Richard Harter) writes:

    > On Mon, 09 Mar 2009 13:11:39 GMT, James Kuyper
    > <> wrote:
    >
    >
    >>The reason that still applies is name space pollution. As libraries
    >>(standard and otherwise) continue to proliferate, I shouldn't have to be
    >>aware of the hundreds (or even thousands) of different identifiers that
    >>are in use by all of those libraries, so I can avoid using them in a
    >>conflicting way in my program. I should only have to worry about the
    >>identifiers used by the parts of those libraries that I'm actually using.

    >
    > In the category of "if only they had" is if only they had put all
    > of an include file's identifiers in a struct name space pollution
    > wouldn't have been nearly as much of a problem. I grant that
    > writing io.printf rather than printf or math.cos rather that cos
    > takes more characters, but so what.


    That would have needed another change that only came later. In "old
    C", a function name was an expression of type "function returning..."
    and an expression of this type was required in front of the function
    call operator. In other words, you'd have to have written
    (*io.printf)("...", ...);

    I am not sure when the function call operator switched to taking a
    pointer, but it simplified a few things in semantics.

    --
    Ben.
     
    Ben Bacarisse, Mar 9, 2009
    #18
  19. James Kuyper <> writes:

    > pete wrote:
    > ...
    >> K&R C had just one standard header, <stdio.h>.

    >
    > I learned C very shortly after K&R I first came out. I remember
    > thinking "If almost every non-trivial C program requires #include
    > <stdio.h>, why don't they just make it implicit?".


    Speed and memory usage come to mind. On slow machines with little
    memory you wanted most modules to compile with as few headers as
    possible. With some programs you had to move stuff around between
    modules just to get it through the compiler.

    --
    Ben.
     
    Ben Bacarisse, Mar 9, 2009
    #19
  20. karthikbalaguru

    Bartc Guest

    "Dik T. Winter" <> wrote in message
    news:...
    > In article <Ls9tl.4871$> "Bartc"
    > <> writes:
    > ...
    > > It would be a nuisance, which is the case with many of the extra types,
    > > constants and functions that other languages have built-in but C chooses
    > > to
    > > put into headers.

    >
    > Algol 68 also had the extra types, constants and functions not built-in in
    > the compiler. I have used an Algol 68 compiler where you could compile
    > with or without the standard environment.


    Don't know too many recent languages, but from what I remember of Fortran,
    Algol, Cobol and Pascal, they didn't seem to need all this business of
    having to declare things that are considered part of the language. And this
    was on machines not much more advanced that what C was developed on.

    However a lot of other languages I've looked at do seem to be full of Use
    and Import and such statements, even for libraries as basic as maths, so I
    can only conclude those designers were over-exposed to C.

    > Compiling without was necessary
    > when compiling the standard environment itself.


    Developing the standard libraries for a language seems rather specialised
    and it's simple enough to have a compiler switch to turn off standard
    includes when this work is being done.

    --
    Bartc
     
    Bartc, Mar 9, 2009
    #20
    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. paul calvert
    Replies:
    6
    Views:
    2,192
  2. Replies:
    18
    Views:
    1,927
    crazzybugger
    Oct 22, 2006
  3. Replies:
    2
    Views:
    567
    Victor Bazarov
    Sep 7, 2005
  4. freeholder
    Replies:
    3
    Views:
    226
    Ilya Zakharevich
    Aug 4, 2006
  5. Replies:
    2
    Views:
    416
Loading...

Share This Page