[Courses] [C] C Variables: summary of discussion
Mary
mary-linuxchix at puzzling.org
Tue Jul 9 16:26:39 EST 2002
I got very caught up in university work, but here at last is our
variables in C summary. I'll announce the next topic soon.
This page is at
http://www.linuxchix.org/content/courses/c_programming/variables.html
If you see mistakes or think it should be reworded - post a reply!
Variables in C
Online references:
* [1]Constant and Variable Types
* [2]Variables
* [3]Identifiers
* [4]typedefs, structs and enums
* [5]Memory allocation
Scope of variables
Kevin posted about scope of variables. A variable's scope is the part
of the program in which using the variable name makes sense. In C, a
variable can be declared at the start of any block eg
{
int b;
/* more code here */
}
and you can refer to it within that block but not outside it:
{
int b;
b = 7; /* will put 7 in the piece of memory called b */
}
b = 8; /* will probably cause a compile error, because outside its block b
isn't defined */
Mary found [6]some example code demonstrating scopes.
Kevin wrote about his understanding of [7]static scoping in C.
Why so many types?
This discussion depends on a tiny bit of knowledge of how assembly
code works, see this [8]very brief overview and [9]section 4 of the
x86 assembly FAQ.
However, it is simply important here to know that when you compile a C
program it is translated into CPU-specific machine code. When we talk
about instruction sets below, we mean the assembly instructions that
your code was translated into, not the C code itself.
a bit is a single value, set to 0 or 1. A byte is eight bits and can
store every number between 0 and 255, using binary notation.
Val [10]asked if anyone was interested in why there are so many C
types (int, char, float and so on.
Julie [11]wrote that C needs to run on all sorts of processors with
all byte sizes.
Mary [12]wrote that:
The basic model of a computer processer is that values are loaded
from memory into registers, which are pieces of memory directly
accessible to the CPU. The CPU can not manipulate values from
memory, it can only access the registers.
There are a very small number of registers, somewhere in the range
of ten to fifty depending on your processor model (and they're much
faster to access than RAM too). There are two types of register for
storing data - integer registers, and floating point registers.
Now, different processors have different size registers. Some have
16 bit registers (they can store 2^16 different numbers), some have
32 bit registers (they can store 2^32 different numbers) and some
have 64 bits, or 8 bits. This is why C integers are not meant to be
a specific size.
The reason for this is that there are some differences between
performing arithmetic on integer (whole number) data and floating
point (real number data, stored to a limited number of significant
figures) arithmetic and the processer does integer arithmetic
differently from floating point arithmetic. So C makes this
distinction too.
Julie [13]noted that this is only true of RISC (reduced instruction
set) architectures, and that CISC (complex instruction set)
architectures can manipulate values in memory. She also wrote that
there are many architectures that use registers that aren't even
multiples of 8, such as 24, 36 or 48 bit registers. Floating point is
generally 16 or 32 bits, and doubles twice the size of that.
The point is: we have all these different types so that no matter
which machine you are working on, you can declare something to be an
int, and know that you are getting a single register worth of memory.
Val [14]explained though that sometimes hardware drivers will need to
copy a value from the hardware which is exactly 8 bits, in which case
header files that define the size of 8 bits in terms of shorts, ints
or longs will need to be used.
References
1. http://www.strath.ac.uk/IT/Docs/Ccourse/section3_6.html#SECTION0006000000000000000
2. http://www.hull.ac.uk/Hull/CC_Web/docs/cnotes/c5.html
3. http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.2.html
4. http://www.ssec.wisc.edu/~dglo/c_class/odds_n_ends.html
5. http://www.cs.colorado.edu/homes/zorn/public_html/MallocDebug.html
6. http://www.cas.mcmaster.ca/~eng1d04/20012002/tm2/slides/Varscope.htm
7. http://mailman.linuxchix.org/pipermail/courses/2002-June/000532.html
8. http://www.piesoftwareinc.co.uk/textonly/asm.html
9. http://www2.dgsys.com/~raymoon/faq/gen1.html#4
10. http://mailman.linuxchix.org/pipermail/courses/2002-June/000518.html
11. http://mailman.linuxchix.org/pipermail/courses/2002-June/000526.html
12. http://mailman.linuxchix.org/pipermail/courses/2002-June/000522.html
13. http://mailman.linuxchix.org/pipermail/courses/2002-June/000527.html
14. http://mailman.linuxchix.org/pipermail/courses/2002-June/000529.html
More information about the Courses
mailing list