Quote:
|
Originally Posted by redfiretruck
|
I glanced at that link, and it seems correct. However, there's something I'd like to add. C does not have support for expressing numbers (in your source) as binary. You can pick decimal (the default), octal (base 8), and hexadecimal (base 16). Hexadecimal is particularly useful.
First, if you have a four-digit binary number, it can store 2 to the power of 4 (generally written as 2^4 on forums and such, when we can't actually use a superscript for the exponent). This means it can store 16 different values. A hexadecimal digit, by its very nature, can also store one of 16 different values; we can thus represent four binary digits with one hex digit.
I mean, what's easier to type, of these two numbers?
11111110110111000100001100100001 (a 32-bit binary number)
FEDC4321 (the same value, expressed as hexadecimal)
Hexadecimal numbers are also preferable to decimal in some cases, especially when expressing powers of two. For example, here is a series of numbers, with each being double the preceding number:
0001
0002
0004
0008
0010
0020
0040
0080
0100
0200
0400
Note how they are all four digit numbers. I can represent any number from 0 to 65535 (or -32768 to -32767, if it's signed) with four hexadecimal digits, not counting the 0x prefix; this is less than the number of decimal digits I'd need. Things also line up nicer if I'm declaring constants in hexadecimal:
#define BIT_0 0x01
#define BIT_1 0x02
#define BIT_2 0x04
#define BIT_3 0x08
#define BIT_4 0x10
#define BIT_5 0x20
#define BIT_6 0x40
#define BIT_7 0x80
Contrast this with the same code using decimal:
#define BIT_0 1
#define BIT_1 2
#define BIT_2 4
#define BIT_3 8
#define BIT_4 16
#define BIT_5 32
#define BIT_6 64
#define BIT_7 128
Granted, the difference doesn't seem like a lot here, but this is for only eight bits. If you've got a 32-bit value, and each bit is used for a flag, you get code like:
#define BIT_31 0x80000000
instead of:
#define BIT_31 2147483648
You tell me which is easier to read.
In C, you will express these numbers with the prefix '0x' (that's a zero, not an uppercase 'o'). This is because hexadecimal numbers can have letters in them; the letters A through F are used to represent the values 10 through 15 in a single digit (since decimal doesn't have enough symbols, we needed to adopt some from the alphabet). If you didn't use the prefix, and had a number such as FE75, the compiler would consider this a variable name (since it doesn't start with a number). Make it 0xFE75, and the compiler knows it's a hex number.
For quick reference, just as the digits for decimal go 0, 1, 2, 3, 4, 5, 6, 7, 8, and finally 9, hexadecimal digits go 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and finally F. Note that although I write them in uppercase, most times it doesn't matter (C compilers don't care). I just find it clearer when the letters are uppercase.
Quote:
|
Originally Posted by redfiretruck
I have read that chars are representated by integers correct? Such as Char 'A' is 65? Well, how does the computer recognize the difference between 65 and A? Just wondering ^_^.
|
All values stored by your computer are binary numbers; as such, they are a series of one or more bits. A byte is defined as the smallest unit you can directly address (ie, you cannot directly read or write a single bit); on almost all modern systems, a byte is synonymous with an eight-bit value. Don't make the mistake of thinking a byte is always eight bits, though; if you want to be clear, either say 'eight-bit byte', or use the term 'octet' (meaning an eight-bit value).
Now, as for the computer knowing how to interpret a value? Well, that depends what you declared it as, and what functions you use. You will also note that some of the C standard functions that you might think would return a single
char actually return an
int instead; this is because an
int can represent values that a
char typically cannot, and these values can be used to signal an error condition. For example, assume that a valid character will be in the range of 0 to 255, and an error is signaled by 0xFFFF (65535 or -1, depending on whether the value is signed or not). Either way, the error return value is outside the range of valid non-error values.
Short answer: they're all numbers to the computer; their significance depends on how you use them.
Quote:
|
Originally Posted by redfiretruck
Also... When i read through stuff like source codes and the example listed above that is in code... Even with comments, they are confusing and take a few minutes to understand? Is that normal for someone starting out?
|
Yup. It's also a
lot harder, in many cases, to read code written by someone else than to write your own. When you're writing your own, all you have to do is figure out how to express a problem to the compiler. When you're reading someone else's code, you not only have to figure out
what they are doing, but
why they are doing it; this is what makes it difficult. It's also why short and sweet examples that illustrate a language feature without unnecessary extras are valuable (I think many examples on MSDN fall short of this simplicity requirement). However, as you begin to make sense of code written by others, your skills will become that much stronger.