C/the.ansi.c.programming.language/notes.accompany.ansi.c/sx10e.html

   1 <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
   2 <!-- This collection of hypertext pages is Copyright 1995, 1996 by Steve Summit. -->
   3 <!-- This material may be freely redistributed and used -->
   4 <!-- but may not be republished or sold without permission. -->
   5 <html>
   6 <head>
   7 <link rev="owner" href="mailto:scs@eskimo.com">
   8 <link rev="made" href="mailto:scs@eskimo.com">
   9 <title>section 7.5: File Access</title>
  10 <link href="sx10d.html" rev=precedes>
  11 <link href="sx10f.html" rel=precedes>
  12 <link href="sx10.html" rev=subdocument>
  13 </head>
  14 <body>
  15 <H2>section 7.5: File Access</H2>
  16
  17 page 160
  18 <p>We've come an amazingly long way without ever having to open a file
  19 (we've been relying exclusively
  20 on those predefined standard input and output streams)
  21 but now it's time to take the plunge.
  22 </p><p>The concept of a <dfn>file pointer</dfn> is an important one.
  23 It would theoretically be possible
  24 to mention the name of a file
  25 each time it was desired to read from or write to it.
  26 But such an approach would have a number of drawbacks.
  27
  28 Instead,
  29 the usual approach
  30 (and the one taken in C's stdio library)
  31 is that you mention the name of the file once,
  32 at the time you <dfn>open</dfn> it.
  33 Thereafter, you use some little
  34 token--in
  35 this case,
  36 the file
  37 pointer--which
  38 keeps track
  39 (both for your sake and the library's)
  40 of which file you're talking about.
  41 Whenever you want to
  42 read from or write to
  43 one of the files you're working with,
  44 you identify that file
  45 by using the file pointer
  46 you obtained from <TT>fopen</TT> when you opened the file.
  47 (It is possible to have several files open,
  48 as long as you use distinct variables to store the file pointers.)
  49 </p><p>Not only do you not need to know the details of a <TT>FILE</TT> structure,
  50 you don't even need to know what the ``buffer'' is
  51 that the structure contains the location of.
  52 </p><p>In general, the only declaration you need for a file pointer
  53 is the declaration of the file pointer:
  54 <pre>   FILE *fp;
  55 </pre>You should never need to type the line
  56 <pre>   FILE *fopen(char *name, char *mode);
  57 </pre>because it's provided for you in <TT>&lt;stdio.h&gt;</TT>.
  58 </p><p>If you skipped section 6.7, you don't know about <TT>typedef</TT>,
  59 but don't worry.
  60 Just assume that <TT>FILE</TT> is a type, like <TT>int</TT>,
  61 except one that is defined by <TT>&lt;stdio.h&gt;</TT> instead of
  62 being built into the language.
  63 Furthermore,
  64 note that you will never be using variables of type <TT>FILE</TT>;
  65 you will always be using pointers to this type,
  66 or <TT>FILE *</TT>.
  67 </p><p>A ``binary file''
  68 is one which is treated as an arbitrary series of byte values,
  69 as opposed to a text file.
  70 We won't be working with binary files,
  71 but if you ever do,
  72 remember to use <TT>fopen</TT> modes
  73 like <TT>"rb"</TT> and <TT>"wb"</TT> when opening them.
  74 </p><p>page 161
  75 </p><p>We won't worry too much about error handling for now,
  76 but if you start writing production programs,
  77 it's something you'll want to learn about.
  78 It's extremely annoying for a program to say
  79 ``can't open file''
  80 without saying <em>why</em>.
  81 (Some particularly unhelpful programs
  82 don't even tell you which file they couldn't open.)
  83 </p><p>On this page we learn about four new functions,
  84 <TT>getc</TT>, <TT>putc</TT>,
  85 <TT>fprintf</TT>, and <TT>fscanf</TT>,
  86 which are just like functions that we've already been using
  87 except that they let you specify a file pointer
  88 to tell them which file
  89 (or other I/O stream)
  90 to read from or write to.
  91 (Note that for <TT>putc</TT>,
  92 the extra <TT>FILE *</TT> argument comes last,
  93 while for <TT>fprintf</TT> and <TT>fscanf</TT>,
  94 it comes first.)
  95 </p><p>page 162
  96 </p><p><TT>cat</TT> is about the most basic
  97 and important
  98 file-handling program there is
  99 (even if its name is a bit obscure).
 100 The <TT>cat</TT> program on page 162 is a bit like the
 101 ``hello, world'' program on page 6--it may seem trivial,
 102 but if you can get it
 103 to work,
 104 you're over the biggest first hurdle
 105 when it comes to handling files at all.
 106 </p><p>Compare the <TT>cat</TT> program
 107 (and especially its <TT>filecopy</TT> function)
 108 to the file copying program on page 16 of
 109 section 1.5.1--<TT>cat</TT> is essentially the same program,
 110 except that it accepts filenames on the command line.
 111 </p><p>Since
 112 the authors advise calling <TT>fclose</TT>
 113 in part to
 114 ``flush the buffer in which <TT>putc</TT> is collecting output,''
 115 you may wonder why
 116 the program at the top of the
 117 page does not call <TT>fclose</TT> on its output stream.
 118 The reason can be found in the next sentence:
 119 an implicit <TT>fclose</TT> happens automatically for any streams which
 120 remain open when the program exits normally.
 121 </p><p>In general,
 122 it's a good idea to close any streams you open,
 123 but not to close the preopened streams
 124 such as <TT>stdin</TT> and <TT>stdout</TT>.
 125 (Since ``the system'' opened them for you
 126 as your program was starting up,
 127 it's appropriate to let it close them for you as your program exits.)
 128 </p><hr>
 129 <p>
 130 Read sequentially:
 131 <a href="sx10d.html" rev=precedes>prev</a>
 132 <a href="sx10f.html" rel=precedes>next</a>
 133 <a href="sx10.html" rev=subdocument>up</a>
 134 <a href="top.html">top</a>
 135 </p>
 136 <p>
 137 This page by <a href="http://www.eskimo.com/~scs/">Steve Summit</a>
 138 // <a href="copyright.html">Copyright</a> 1995, 1996
 139 // <a href="mailto:scs@eskimo.com">mail feedback</a>
 140 </p>
 141 </body>
 142 </html>