| blob | c2137f7d2a18ffc81615d81ec13d725141ad0ef8 |
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>
13 </head>
14 <body>
17 page 2
18 <p>Deep sentence:
19 <blockquote>...C deals with the same sort of objects that most computers do,
20 namely characters, numbers, and addresses.
21 </blockquote>C is sometimes referred to as a ``high-level assembly language.''
22 Some people think that's an insult,
23 but it's actually a deliberate and significant aspect of the language.
24 If you have programmed in assembly language,
25 you'll probably find C very natural and comfortable
26 (although if you continue to focus too heavily on machine-level details,
27 you'll probably end up with unnecessarily nonportable programs).
28 If you haven't programmed in assembly language,
29 you may be frustrated by C's lack of certain higher-level features.
30 In either case,
31 you should understand why C was designed this way:
32 so that seemingly-simple constructions expressed in C
33 would not expand to arbitrarily expensive
34 (in time or space)
35 machine language constructions when compiled.
36 If you write a C program simply and succinctly,
37 it is likely to result in a succinct, efficient machine language executable.
38 If you find that the executable
39 resulting from a C program is not efficient,
40 it's probably because of something silly you did,
41 not because of something the compiler did behind your back
42 which you have no control over.
43 In any case,
44 there's no point in complaining about C's low-level flavor:
45 C is what it is.
46 </p><p>Next
47 we see a more detailed list of the things that are not
48 ``part of C.''
49 It's good to understand exactly what we mean by this.
50 When we say that the C language proper
51 does not do things like memory allocation or I/O,
52 or even string manipulation,
53 we obviously do not mean that there is no way to do these
54 things in C.
55 In fact, the usual functions for doing these things are
56 specified by the ANSI C Standard with as much rigor as
57 is the core language itself.
58 </p><p>The fact that things like memory allocation and I/O are done
59 through function calls has three implications:
61 the function calls to do memory allocation, I/O,
62 etc. are no different from any other function calls;
64 the functions which do memory allocation, I/O,
65 etc. do
66 not know any more about the data they're acting on than
67 ordinary functions do
68 (we'll have more to say about this later);
69 and
71 if you have specialized needs,
72 you can do nonstandard memory allocation or I/O
73 whenever you wish, by using your own functions
74 and ignoring the standard ones provided.
75 <p>The sentence that says
76 ``Most C implementations have included
77 a reasonably standard collection of such functions''
78 is historical;
79 today,
80 all implementations conforming to the ANSI C Standard
81 have a very standard collection.
83 </p><p>Deep sentence:
84 <blockquote>...C retains the basic philosophy that programmers know what they are doing;
85 it only requires that they state their intentions explicitly.
86 </blockquote>This aspect of C is very widely criticized;
87 it is also used (justifiably) to argue
88 that C is not a good teaching language.
89 C aficionados love this aspect of C because it means that C
90 does not try to protect them from themselves:
91 when they know what they're doing,
92 even if it's risky or obscure,
93 they can do it.
94 Students of C
95 hate this aspect of C because it often
96 seems as if the language is some kind of a conspiracy
97 specifically designed to lead them into booby traps and
98 ``gotcha!''s.
99 </p><p>This is another aspect of the language which it's fairly
100 pointless to complain about.
101 If you take care
102 and pay attention,
103 you can avoid many of the pitfalls.
104 These notes
105 will point out many of the obvious
106 (and not so obvious)
107 trouble spots.
109 </p><p>The last sentence of the Introduction is misleading:
110 as we'll see,
111 it's risky to defer to any particular compiler as a
112 ``final authority on the language.''
113 A compiler is only a final authority on the language it accepts,
114 and the language that a particular compiler accepts
115 is not necessarily exactly C,
116 no matter what the name of the compiler suggests.
117 Most compilers accept extensions
118 which are not part of standard C
119 and which are not supported by other compilers;
120 some compilers are deficient
121 and fail to accept certain constructs which are in standard C.
122 From time to time,
123 you may have questions about what is truly standard
124 and which neither you nor anyone you've talked to is able to answer.
125 If you don't have a copy of the standard
126 (or if you do,
127 but
128 you discover that
129 the standardese in which it's written is impenetrable),
130 you may have to temporarily accept the jurisdiction of your
131 particular compiler,
132 in order to get some program working today and under that particular compiler,
133 but you'd do well to mark the code in question as suspect
134 and
135 the question in your head as ``don't know; still unanswered.''
136 </p><hr>
137 <p>
138 Read sequentially:
143 </p>
144 <p>
148 </p>
149 </body>
150 </html>