Printable View
How does a variable's amount of space used correlate to its ablity to hold data. For example do a Char and an Int use the same amount of memory, or does a Char use less because it only needs to store numbers 0-255? Also if a charecter is written to a file does the file really contain 3 numbers representing the letter, or is it saved in bianary (or perhaps some other base system)?
Thanks,
Greg
The type size is most definitely related to the number range. Using your example, a char is represented by a byte(8-bits) because it has values of 0-255 and you only need 8-Bits to represent 0-255.
different data types have take up different amounts of space...
usaually Integer is 4 bytes.... and char 1 byte....
you can easily determine the size of a certain data type by calling a "sizeof" function...
when you write data to a file it depends on what kind of a mode u r using...Code:
int SomeInt = 5;
cout << sizeof(SomeInt);
you can write in binary or text..... depends on what you specify....
Regards,
matheo917
The size of a varible directly reflects the range of data it can store.
The maximum number of combinations (range of values) a variable can store is essentially two to the power of its size in bits.
For example on my system I get char as 1 byte.
This means that it can hold 2^8 or 256 different values.
I get an int as 4 bytes so it can hold about 2^32 or 4294967296 differnet values.
And as to files, they must be stored in bnary on a hard disk. And i'd assume that they are just stored as sequential stream of char's so it'd only take 1 byte per character.
>The type size is most definitely related to the number range
on the contrary i might have had the converse be the initial statement. if saying the range defines the size... but nontheless... that would be correct...
Alternatively to the above posted code..
you can also write it like this...Code:int SomeInt = 5;
cout << sizeof(SomeInt);
Just for your informationCode:
cout << sizeof( int );
yes... it's advantageous to rely on the base types themselves, as if you have pointers and memory buffers you might get an incorrect size value [when, for example, you meant to have the base type... and viceversa]...
You are absolutely right, i stand corrected. The range is a product of the type size would have been a more correct statement.Quote:
Originally posted by doubleanti
>The type size is most definitely related to the number range
on the contrary i might have had the converse be the initial statement. if saying the range defines the size... but nontheless... that would be correct...
the byte size of a type is completely compiler dependent. For instance, if a compiler wanted to exclusively use unicode for characters instead of ascii then the char type would be atleast 2 bytes. It's possible that more than 2 bytes could be used, but that would be impractical for unicode since it itself is a 2byte code (and 65 thousand characters should be enough for all the languages of the world).
For anyone dealing with binary formatted files or streaming binary data over sockets, the size of data types is a really thorny subject.
The Ansi C standard defines integer sizes as:
char <= short <= int <= long
But it doesn't define the actual sizes themselves. Hence sizes may depend on which platform your software was built for. Typically, they currently have the following sizes:
char is 8 bits
short is 16 bits
int is 32 bits
long is 32 bits
However, it doesn't have to be this way. I believe that on some 64 bit Solaris machines, an int can be 64 bit. To get around this, you can use the following __int8, __int16, __int32. However, these types are not Ansi standard, but I believe they are supported by most compilers.
A couple of the other things to bear in mind:
1. The size of structures depend on the data alignment setting of your compiler. If you are using the 32 bit alignment, the size of a structure containing just a char and an int will be 64 bits (not 40 bits). It is sized to the nearest 32 bit multiple. This can cause problems for different programs reading the same binary data if your not careful.
2. Byte Order. Different CPU architectures use different byte orders for integers and floats. Hence an integer written to a binary file by a PC based program will appear as a different value when read by a program on a HP platform, unless care has been used to define the byte order. Typically, you should 'Network Byte Order'. I believe the standard socket libraries have conversion functions for these.
> but that would be impractical for unicode since it itself is a 2byte code
Correct me if I'm wrong, but I believe there are several schemes for unicode. 2 Byte code is UCF16. And as 65,000 characters are NOT enough for all the languages of the world, there is a UCF32 standard.
There's a 'multi-byte' standard also, where characters below 128 are treated a single byte, but other characters can have different sizes (up to 6 bytes I believe). Sounds complicated :(
>completely compiler dependent
not completely... it's also processor dependant... :)
oh and variable length language character encoding? wow, that's reminscent of RLE-encoding... isn't it? i'm interested in this UCFxx, where can i find any good resources? thank you...
as to files....all files are stored on the storage media (hard drive, floppy, zip, whatever, in binary and are not inherently readable to the average human. The OS converts the binary data to a readable form when displayed in a text editor so it appears as though it were stored as text, but it's not. The transparency is so complete however, that you can think of files as being text based if you wish.
When using VC++ I like to use the data types __int8 __int16 __int32 and __int64, they are great for constants since you'll know at compile time how big they need to be and you can use as few bytes as you need, I usually define unsigned so that I can have a larger upper boundary since signed will use have of the values for negative and half for positive.