| blob | 292426ee8b29d505551eb5c62e07578d2706b48f |
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>
18 but they're quite important,
19 so you'll need to learn them well.
20 Usually,
21 conversions happen automatically and when you want them to,
22 but not always,
23 so it's important to keep
24 the rules in mind.
26 </p><p>Deep sentence:
29 </blockquote>Whether you treat a ``small integer'' as a character
30 or an integer is pretty much up to you.
31 As we saw earlier,
32 in the ASCII character set,
34 Therefore, saying
36 </pre>is the same as saying
39 using
40 <pre> putchar(i);
41 </pre>or
45 If you print it out as a number:
48 </p><p>Most of the time,
49 you'll use whatever notation matches what you're trying to do.
52 If you want the value 48
53 (as the number of months in four years, or something),
55 If you want to print characters,
57 and if you want to print integers,
59 Occasionally, you'll cross over between
60 thinking of characters as characters and as values,
64 and you should never have to write code which depends on it.)
66 </p><p>To illustrate the ``schitzophrenic'' nature of characters
67 (are they characters, or are they small integer values?),
68 it's useful to look at an implementation of the standard
70 (If you're getting overwhelmed, though, you may skip this
71 example for now, and come back to it later.)
73 into an integer having the corresponding value.
77 </p><p>The expression
79 </pre>is an example of the ``crossing over''
80 between thinking about a character and its value.
82 (and, similarly, the other numeric characters
83 don't have their ``obvious'' values, either),
84 we have to do a little conversion
87 Since
88 the character set values for
91 the conversion involves simply subtracting an offset,
92 and the offset
93 (if you think about it)
95 We could write
97 </pre>if we really wanted to,
98 but that would require knowing what the value actually is.
99 We shouldn't have to know
100 (and it might be different in some other character set),
101 so we can let the compiler do the dirty work
104 by definition,
107 here without a lot of fanfare.
112 </pre></p><p>Don't worry too much about the discussion of
113 signed vs. unsigned characters for now.
114 (Don't forget about it completely, though;
115 eventually,
116 you'll find yourself working with a program where the issue is significant.)
117 For now, just remember:
121 <li>If you're ever dealing with arbitrary ``bytes'' of binary data,
125 relational and logical operators always ``return'' 1 for ``true''
126 and 0 for ``false.''
127 However,
128 when C wants to know whether something is true or false,
129 it just looks at whether it's nonzero or zero,
130 so any nonzero value is considered ``true.''
131 Finally,
132 some functions which return true/false values
134 may return ``true'' values of other than 1.
135 </p><p>You don't have to worry about these distinctions too much,
136 and you also don't have to worry about the fragment
138 </pre>as long as you write conditionals in a sensible way.
139 If you wanted to see
141 you'd never write
146 they're equal).
147 Similarly,
148 you don't want to write
150 </pre>because it's equally silly-looking,
152 Just write things like
153 <pre> if(a == b)
154 </pre>and
155 <pre> if(isdigit(c))
156 </pre>and you'll steer clear of most problems.
157 (Make sure, though, that you never try something like
159 since this wouldn't do at all what it looks like it's supposed to.)
161 though informally stated,
162 is exactly the set to remember for now.
163 They're easy to remember if you notice that,
164 as the authors say,
166 where the ``order'' of the types is
169 so you don't need to worry about it.)
170 We'll have more to say about these rules on the next page.
171 </p><p>Don't worry too much for now
173 because we won't be using them at first.
174 </p><p>Do notice that implicit (automatic) conversions do happen
175 across assignments.
176 It's perfectly acceptable to
178 or
180 (or any other combination).
181 Obviously, when you assign a value from a larger type to a
182 smaller one,
183 there's a chance that it might not fit.
184 Therefore, compilers will often warn you about such assignments.
189 A cast consists of a type name in parentheses
190 and is used as a unary operator.
191 You may have used languages
192 which had conversion operators
193 which looked more like function calls:
195 floating f = floating(i); /* not C */
196 integer i2 = integer(f); /* not C */
197 </pre>
198 In C,
199 you accomplish the same thing with casts:
201 float f = (float)i;
202 int i2 = (int)f;
203 </pre>(Actually, in C,
204 we wouldn't need casts in those initializations at all,
206 are some of the ones that C performs automatically.)
207 </p><p>To further understand both how implicit conversions
208 and explicit casts work,
209 let's study how the implicit conversions would look
210 if we wrote them out explicitly.
211 First we'll declare a few variables of various types:
212 <pre> char c1, c2;
213 int i1, i2;
214 long int L1, L2;
215 double d1, d2;
216 </pre>Next we'll look at the kinds of conversions which C
217 automatically performs when performing arithmetic on two
218 dissimilar types, or when assigning a value to a dissimilar type.
219 The rules are straightforward:
220 when performing arithmetic on two dissimilar types,
221 C converts one or both sides to a common type;
222 and when assigning a value,
223 C converts it to the type of the variable being assigned to.
225 <pre> i2 = c1 + i1;
227 as if we'd written
228 <pre> i2 = (int)c1 + i1;
230 <pre> d2 = L1 * d1;
232 as if we'd written
233 <pre> d2 = (double)L1 * d1;
235 <pre> i1 = c1;
236 </pre>is as if we'd written
237 <pre> i1 = (int)c1;
238 </pre>and
240 <pre> i1 = f1;
241 </pre>is as if we'd written
242 <pre> i1 = (int)f1;
243 </pre></p><p>Some programmers worry that implicit conversions are somehow unreliable
244 and prefer to insert lots of explicit conversions.
245 I recommend that you get comfortable with implicit
246 conversions--they're quite useful--and don't clutter your
247 code with extra casts.
248 </p><p>There are a few places where you do need casts, however.
249 Consider the code
251 i2 = 400;
252 L1 = i1 * i2;
253 </pre>The product
257 values up to 32767.)
259 you might think that you're okay, but you're not:
260 the two sides of the multiplication are of the same type,
261 so the compiler doesn't see the need to perform any automatic conversions
262 (none of the rules on page 44 apply).
263 The
265 which overflows with unpredictable results,
266 and only after the damage has been done is the unpredictable
268 To get a multiplication like this to work,
271 <pre> L1 = (long int)i1 * i2;
272 </pre>Now,
275 (by the fifth rule on page 44),
277 If it makes you feel safer, you can use two casts:
278 <pre> L1 = (long int)i1 * (long int)i2;
279 </pre>but only one is strictly required.
280 </p><p>A similar problem arises when two integers are being divided.
281 The code
283 f1 = i1 / 2;
285 Again,
287 (the rules on page 44 still don't apply),
288 so an integer division is performed,
289 which discards any fractional part.
291 Again, an explicit conversion saves the day:
293 </pre>Alternately,
294 in a case like this,
295 you can use a floating-point constant:
297 </pre>In either case,
298 as soon as one of the operands is floating point,
299 the division is carried out in floating point,
300 and you get the result you expect.
301 </p><p>Implicit conversions always happen during arithmetic and
302 assignment to variables.
303 The situation is a bit more complicated when functions are
304 being called, however.
306 which is as good an example as any.
310 and if you called
312 </pre>or
314 sqrt(n);
318 Therefore,
319 it was once
320 always
321 necessary to use explicit conversions in cases like
322 this,
323 by calling
325 </pre>or
326 <pre> sqrt((double)n)
327 </pre>or
329 </pre></p><p>However,
330 it is now possible,
332 to tell the compiler what types of arguments a function expects.
334 <pre> double sqrt(double);
335 </pre>and as long as a prototype is in effect
336 (``in scope,'' as the cognoscenti would say),
338 When a prototype is in effect,
339 the compiler performs implicit conversions during function calls
340 (specifically, while passing the arguments)
341 exactly as it does during simple assignments.
342 </p><p>Obviously, using prototypes makes for much safer programming,
343 and it is recommended that
344 you use them
345 whenever possible.
346 For the standard library functions
347 (the ones already written for you),
348 you get prototypes automatically
350 sets of library functions.
351 For example,
352 you
353 get prototypes for all of C's built-in math functions
354 by putting the line
356 </pre>at the top of your program.
357 For functions that you write,
358 you can supply your own prototypes,
359 which
361 we'll be learning more about later.
362 </p><p>However, there are a few situations
363 (we'll talk about them later)
364 where prototypes do not apply,
365 so it's important to remember that function calls are a bit
366 different
367 and that
368 explicit conversions (i.e. casts) may
369 occasionally be required.
370 Don't imagine that prototypes are a panacea.
373 </p><hr>
374 <p>
375 Read sequentially:
380 </p>
381 <p>
385 </p>
386 </body>
387 </html>